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.
An expired file is a file that the server no longer needs to keep, according to policy. Files expire under the following conditions
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 Image 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.
Also Read: How TSM Server determines the eligibility of files during different types of backup ?
This website is remarkable information and facts it's really excellent
ReplyDeleteBridal Jewellery
Ho does happen data expiration in SAP for Oracle ERP system if we allow
ReplyDelete"MAX_VERSIONS 14 " parameter in ERP end?
Data Protection for SAP uses version control for managing SAP database
ReplyDeletebackups 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)
MAX_VERSIONS n|4
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
characteristics:
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
deleted.
--------------------------------------------------------------------------------
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
MAX_VERSIONS=0.
--------------------------------------------------------------------------------