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...

3 Responses to "How TSM expiration process deletes old backups ?"

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

  2. Ho does happen data expiration in SAP for Oracle ERP system if we allow
    "MAX_VERSIONS 14 " parameter in ERP end?

  3. Data Protection for SAP uses version control for managing SAP database
    backups by backing up all data to only those management classes for which an
    archive copy group is defined (typearchive). To prevent backed up files within
    IBM Spectrum Protect server storage from being deleted due to expiration dates
    (IBM Spectrum Protect deletes expired files), the copy group parameter retver,
    which specifies the number of days a file is to be kept, must be set to unlimited
    (9999 or nolimit)


    The n value defines the maximum number of full database backup
    versions to be kept in backup storage. The default setting for this value is
    0, meaning that backup version control is disabled. If the number of
    versions that are found in backup storage is larger than the specified
    maximum number of backup versions (as specified by the parameter
    MAX_VERSIONS), the oldest versions are deleted (together with the
    corresponding table space and redo log files) until only the specified
    maximum number of most recent versions remain. Also, consider these

    A) When IBM Spectrum Protect for ERP deletes an old full backup, all
    partial backups older than this full backup are also deleted.

    B) If the backups are distributed over multiple IBM Spectrum Protect
    servers and one of the servers is temporarily unavailable at the time of a
    new full backup, it is not possible to find all the backup versions. This
    situation might result in retaining a backup that would otherwise be

    IBM Spectrum Protect uses the value of the RETVER parameter (specified
    when a copy group is defined) to give files an expiration date. Use only
    one of these methods to control how long you keep backups:

    A) If you use IBM Spectrum Protect for ERP backup version control, you
    must bypass this expiration function. Set the IBM Spectrum Protect
    parameter RETVER=9999 so that the files are not considered expired and
    are not deleted by IBM Spectrum Protect.

    B) If you use the IBM Spectrum Protect expiration function, turn off IBM
    Spectrum Protect for ERP backup version control. Deactivate IBM
    Spectrum Protect for ERP backup version control by setting