![]() |
![]() |
Over time, media ages, and the data on backup may no longer be needed. You can reclaim useful data on media and then reclaim and reuse the media themselves. When you set up expiration processing, you can determine when data is no longer needed. See File Expiration and Expiration Processing.
TSM policy determines how many backup versions are retained and how long they are retained. See Basic Policy Planning.
You can set a reclamation threshold that allows TSM to reclaim volumes whose valid data drops below a threshold. The threshold is a percentage of unused space on the volume and is set for each storage pool. The amount of data on the volume and the reclamation threshold for the storage pool affects when the volume is reclaimed. See Reclaiming Space in Sequential Access Storage Pools.
Reclaim any valid data from volumes that have reached end of life. If the volumes are in automated libraries, check them out of the volume inventory. Delete private volumes the database. See Reclaiming Space in Sequential Access Storage Pools.
For automated libraries, see Setting Up and Managing a Volume Overflow Location for an Automated Library Device.
Write-once-read-many (WORM) drives can waste media when TSM cancels transactions because volumes are not available to complete the backup. Once TSM writes to WORM volumes, the space on the volumes cannot be reused, even if the transactions are canceled (for example, if a backup is canceled because of a shortage of media in the device).
Large files can cause even greater waste. For example, consider a client backing up a 12GB file onto WORM platters that hold 2.6GB each. If the backup requires five platters and only four platters are available, TSM cancels the backup and the four volumes that were written to cannot be reused.
To minimize wasted WORM media:
If most backups are small files, controlling the transaction size can affect how WORM platters are used. Smaller transactions mean that less space is wasted if a transaction such as a backup must be canceled. Transaction size is controlled by a server option, TXNGROUPMAX, and a client option, TXNBYTELIMIT.