The most powerful thing about TSM is how flexible it can be. There is a way for TSM to meet pretty much any data management requirement. The difficult part is to work out how long you need to keep data for, what rules need to apply. Once you know that setting up TSM is just a matter of following the motions.
TSM performs backups and archives. (as well as restores and retrieves!)
– Backup is typically the file level “incremental forever” type backups.
– Archive is a full backup (eg a monthly backup) to keep for X amount of days.
There are also application driven backups that also go to TSM (TSM for Mail, Databases, ERP, Sharepoint, VMware etc) however what I’m describing here is how TSM manages FILES.
TSM can also perform space management tasks, where old files are removed from the filesystem (a stub file put in their place) and stored on tape to save space on a fileserver, or NAS filesystem (eg the V7000 Unified or a SONAS).
Anyway..
When Tivoli Storage Manager backs up a file (this is backup, not archive as an archive is a full backup kept for a period of days) the file is regarded as the active version of the file. This is the most recent backup copy of the file.
Once TSM runs another backup, it will only back up the file if it has changed, or obviously it will backup new files on the filesystem. TSM also has the ability to backup only changed parts of a file (adaptive subfile backup), as well as hold a journal of changed files to reduce the time it takes to scan a filesystem for changed files.
Once a file is either deleted from the filesystem, or is no longer the most recent backed up version of the file due to change, it is marked inactive by TSM. This means that rules now apply to how the file is handled from this point onwards. These rules govern how many days or versions, or a combination of both the inactive file is retained for. These rules only apply to inactive files, active files are always stored.. always.
THE FILE WILL BE EXPIRED BY TSM BASED ON WHICH OF THE BELOW RULES ARE MET FIRST!
“Versions Existing” is the number of historical versions of each file to retain while the file still exists on the client file system.
“Versions Deleted” is the number of historical versions of each file to retain after the file has been deleted from the client file system.
“Retain Extra” is the number of days to retain the historical versions of each file. After this period older versions will be discarded.
“Retain Only” is the number of days to retain the last remaining historical version of each file. This only applies after the file has been deleted from the client file system, and the RE parameter has discarded all other versions.
“No Limit” specifies that there is no limitation on the number of historical versions retained.
If the requirement is that a file is to be kept for instance for 30 days, there is no real reason to set versions existing or versions deleted, as the requirement is in DAYS. These can be set to no limit. If there is a file that changes regularly and there is a rule for versions deleted or versions existing then there is a risk that the file will be expired based on the number of versions not on the total number of days. There are certain environments where a combination of all of the rules fits perfectly to what the data retention policy is, but there are also cases where there is a risk of this being over-complicated and files expired unknowingly.
So.. what happens if a file is expired can we get it back? It depends. You need a few things to do this:
– Another TSM instance to restore the database to (never restore over production for something like this)
– A database backup
– A copy of the TSM volume history file
– The reusedelay setting set on your storage pool to a number of days back to when the file still existed.
When files are expired from TSM, they simply have their reference to them removed from the TSM database, and TSM now sees the space taken by that file as empty space in the TSM storage pool. If you set reusedelay on your storage pool, TSM will not reclaim / overwrite that space on the tape for X number of days. This protects you against having to go back to an older database backup and restore files.
It is strongly recommended to set reuse delay to 1 day or more, just to protect you.
So, you can potentially get data back after TSM has expired it, so long as you ensure that you have re-use delay turned on for a period that allows you to recover the file.
To avoid ALL of this, just be careful of your TSM management class, copy group and storage pool settings. Like any other backup product, TSM will do what it’s told. If you tell it to expire a file, it will, so be very careful when setting up TSM policy.
Information Technology Knowledgebase 