Updating tivoli backup client
Assume a file is backed up to a management class with a RETONLY value of 30 days.This file becomes inactive on 1/1/2003 because the file was deleted on the client.Current files backed up and future backups stored on the Tivoli Storage Manager server dynamically, and immediately, inherit the new settings, no subsequent backup is required. This is a summary of how the file expiration process works.When a backup object (ie: file) changes from an active to inactive state, it will have a "deactivation date" assigned at the time of the transition.On the sixth night of backups, the oldest inactive version of this file will be marked for deletion because VEREXISTS=5 will only permit the Tivoli Storage Manager server to retain a maximum total of 5 versions of this file.
Versioning parameters are evaluated only at the time of backup. Modifying any Retention related parameters in the copygroup results in the retention setting being applied to all backups using the modified management class/copygoup.Since the evaluation of the versioning settings occurs AT THE TIME OF BACKUP, any changes made to the VEREXISTS and/or VERDELETED parameters, will only be applied on the next backup.For example, a client is backing up to a management class with VEREXISTS=5.The file is then tracked in a server database table entitled: Expiring. The process of file expiration is one where the Tivoli Storage Manager server evaluates the deactivation dates and management class attributes of the entries in the Expiring. Once purged, that particular version of the file can no longer be restored by Tivoli Storage Manager.