How TSM expiration process deletes old backups ?


TSM Client backup or archive physical files are stored in TSM server storage and its meta data is stored in TSM database. When client files are eligible for expiration, the meta data from TSM gets deleted and the space used for storing corresponding client data on tapes can be used for another client backups. Deletion or expiration of meta data from TSM database is completely depend upon the retention settings. You can either manually expire data through Expire Inventory command or let it expire automatically by TSM admin schedules.
expire inventory 

An expired file is a file that the server no longer needs to keep, according to policy. Files expire under the following conditions
  • Users delete file spaces from client nodes.
  • Users expire files by using the EXPIRE or DELETE BACKUP command on the client.
  • A file that is a backup version exceeds the criteria in the backup copy groupAn archived file exceeds the time criteria in the archive copy group 

How backup versions are deleted during Expiration Process

  • There are TWO attributes involved that control how long the Tivoli Storage Manager server stores data. They are: Versioning and Retention. Both attributes work together, thus resulting an a series of possible cases that need to be examined.
  • Modifying any Versioning related parameters in the copygroup requires a backup to be initiated to make the changes take affect (this is known as Management Rebinding). 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. 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.
Also Read: Different types of Incremental Backups
  • 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. The file is then tracked in a server database table entitled: Expiring.Objects (V5). 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.Objects table and purges the appropriate entries. Once purged, that particular version of the file can no longer be restored by Tivoli Storage Manager.
  • A base file is not eligible for expiration until all of its dependent subfiles have been expired.
  • An archive file is not eligible for expiration if there is a deletion hold on it. If a file is not held, it will be handled according to existing expiration processing. The server deletes expired files from the server database only during expiration processing. After expired files are deleted from the database, the server can reuse the space in the storage pools that was occupied by expired files. You should ensure that expiration processing runs periodically to allow the server to reuse space.
Expiration processing also removes from the database any restartable restore sessions that exceed the time limit set for such sessions by the RESTOREINTERVAL server option.

Also Read: How TSM Server determines the eligibility of files during different types of backup ?




What Others are Reading Now...

1 Response to "How TSM expiration process deletes old backups ?"

  1. This website is remarkable information and facts it's really excellent
    Bridal Jewellery

    ReplyDelete