Proper TSM use

[Sporti69]

Hi all,
I am still new to this big backup world of TSM and am a bit confused on how I should properly implement my backup requirements.

- daily backup (able to rollback 14 days)
- monthly backup (able to rollback 2 months)
- quarterly backup (able to rollback 2 quarters)

So I start to create a domain "daily" with a policy, mgmt class, copy group.
Then I create a schedule based upon that domain to run daily, at night
Register a node with the domain and schedule, and I start testing...

- Ok, it works, but not completely. TSM will not hold backups for a number of days, but a number of versions, right? Can live with this.
- How do I automate the other 2 backup requirements of the same node ? (monthly and quarterly).

-Do I use different options files on the same client?
-Am I able to use multiple copygroups,
-do I need different schedulers,
-can I copy backups already taken by the daily backup and use them -once a month/quarter in stead of all of the above
​

or am I now asking questions that are not valid with TSM logics?

Help me to see the light please.

Best Regards
Tom

 

[moon-buddy]

Your mindset is akin to other backup strategies.

In TSM you work with versions and retention periods.

Something like:

This number of versions: 6
Number of days to keep inactive versions: 180

For backup files that a user has deleted from the client node:
Number of versions to keep: 2

Amount of time to keep the last file version
This number of days: 180

Generally, you don't do weekly, monthly, or yearly. You do Backup and/or Archive.

Read "The Tivoli Storage Manager" section found here: http://publib.boulder.ibm.com/infocenter/ieduasst/tivv1r0/index.jsp?

 

[Sporti69]

Ok that is quite clear now. You post confirmed what I came to realize these days.
So now I can rephrase my question in more TSMish ^^

Scenario:
I do a daily scheduled backup of a node
Keep maximun 14 versions that expire after 14 days
This guarantees that i can do a rollback to any of 14 preceding days.

Question
How can i automatically (schedule, maintenance) add more backup requirements to that node. I want the:
- active version on the first of every month be saved for max 60 days and 3 versions
- active version on the first of every year be saved for 700 days and 2 versions

How do I tackle this with TSM?

 

[Mita201]

register two more nodes, eg NODE_M and NODE_Q
create two managament classess that contains backup copy groups with required settings
create two more option files with NODENAME NODE_M and NODENAME NODE_Q statements (you do it a bit differently on win and unices), and management class statements
Now, you can use one scheduler service/daemons on a node, and three schedules defined on a server, for same node ("original one"). First schedule will do daily backups, and other two will call a command on the node, which will call appropriate option file.
Or, you can install/start three scheduler services on node, with different option files each, and define three schedules on server, and associoate appropriate nodes with them.

Or,
You can try to modify your backup policies/requirements to fit TSM way of working.

 

[Sporti69]

That solution is what I want to avoid.

Now how can I do it more like TSM then? Covering short, middle and long term. Meaning 3 dimensions.

For the record I am low on storage and want to limit versions.... Might help you visiualize my needs.

 

[Mita201]

If we are talking about files only - it is quite simple:
Do only daily backups, with 14 versions, and as many days retention you like.
do monthly and quaterly archives, with longer archive settings (quaterly).

 

[Sporti69]

So then I cover short term (backup for 14 days) and archive (monthly and keep it a quarter)...
now how do I add yearly for 2 years ? Is it correct that I cannot add a third dimenision to the automated design as it exists?

Big thanks for the help so far !

 

[Mita201]

You can.
Create additional management class, put appropriate archive copy group settings, and do long term archive with that management class - either with dsmc command that points to appropriate mc or with additional dsm.opt file with same nodename and mc specified to desired one.
When you do archive, it binds to management class which you set at the time of creation, and never rebinds - it stays with mc it has when created
Backups do rebind old backups when you change mc for new backup.

 

[Sporti69]

#1
So you mean that any extra management class will not be the default ... meaning they need to be called with the archmc parameter. Correct?

#2
If #1 is correct ... do you mean that it will not change the default mc after calling another one with archmc?

#3
You say; "or with additional dsm.opt file with same nodename and mc specified to desired one"
Where do you specify mc ? In the incl/excl file?

 

[Jeff_Jeske]

You changed software so you should consider changing/reevaluating your backup needs.

It is my opinion that backup should be for disaster recovery and not monthly archives. A retention of 30 days should be plenty of time for a client to recognize a file was lost and to ask for it back. Our default is 16 versions or 42 days. 16/42/16/42

How often do you go back more than a month to recover lost data? I understand that a file that is only used quarterly may bet accidently removed but you simply can't keep everything forever. Long term point in time archives really don't provide much more coverage.

If you plan to archive more often than one request here and there then an archiving solution with dedup and e-discovery should be put in place to meet those retention requirements.

 

[Mita201]

#1
So you mean that any extra management class will not be the default ... meaning they need to be called with the archmc parameter. Correct?

#2
If #1 is correct ... do you mean that it will not change the default mc after calling another one with archmc?

#3
You say; "or with additional dsm.opt file with same nodename and mc specified to desired one"
Where do you specify mc ? In the incl/excl file?

#1 Correct
#2 It will change it only for archive created when you invoke it; not for older and not for next archives.
#3 Yes, you can write it in incl/excl, or straight into dsm.opt file on win or dsm.sys on unices


Also, I agree with Jeff_Jeske latest post completely.

 

[Sporti69]

Thanks a lot for all the insights guys.

So to summarize proper TSM use for clients with multiple backup requirements:
- create multiple management classes and use the archmc
- this can only be done using archives, and not backups

Or one could create a second domain/node/scheduler.


Everything correct in my post?

 

[Mita201]

Well, going harder way - yes, you are right.
Rethink backup/archive requirements. I know everybody saying this, but I'll say once more.

 

[Darin]

retention setting question

Hello,

I am wondering if I have a file that was made in 2008 and has never changed and then the person deletes it will tivoli start the timer from then or when the file was origanlly backed up. Say I am keeping the last deleted version for 365 days will tivoli expire it because it was made in 2008 or go from the deleted date of say jan 1st 2011

 

[mjaquillard]

Take a look at backupsets, I think they do exactly what you want. You can create a logical group of nodes, and generate a backupset of them when ever you want. The backupset will contain all of the active files for the nodes at the point in time that you create it (or give it a date that you want the active versions from, as long as those file are not expired). This activity could be scheduled to run automatically with some tsm scripts.

The problem with backupsets is that they aren't tracked especially well within TSM. You'll have to look into that to see if it's sufficient for what you need.

Some other benefits to backupsets: although you can restore though the TSM server just like regular backups (as long as you create a table of contents), you can even restore without a TSM server if you have a tape drive directly attached to the system that is restoring.
Backupsets will also make your TSM db grow less than registering additional nodes. I believe there is only one (or at least very minimal) entry added to the TSM db for each backupset since the TSM db doesn't track the individual files in the backupset, just the pointer to the TOC if that was created.

 

[Mita201]

@Darin:
Timer will start at the moment when TSM knows your file have been deleted - in your case at the next backup interval - when TSM client goes trough filespace/directory where file has been deleted from. From that day, last version will expire in 365 days if your policy says so.

 

[Darin]

Thank you, That is what I thought but wanted to be sure before explaning to the stakeholders about the new settings.

Thanks again