![]() |
![]() |
With TSM, you manage your volume inventory by performing the following tasks:
TSM expects to be able to access all volumes it knows about. For example, TSM tries to fill up tape volumes. If a volume containing client data is only partially full, TSM will later request that volume be mounted to store additional data. If the volume cannot be mounted, an error occurs.
To make volumes that are not full available to be read but not written to, you can change the volume access mode. For example, use the UPDATE VOLUME command with ACCESS=READONLY. The server will not attempt to mount a volume that has an access mode of unavailable.
If you want to make volumes unavailable to send the data they contain offsite for safekeeping, a more controlled way to do this is to use a copy storage pool. You can back up your primary storage pools to a copy storage pool and then send the copy storage pool volumes offsite. You can track these copy storage pool volumes by changing their access mode to offsite, and updating the volume history to identify their location. For more information, see Backing Up Storage Pools.
To reuse tapes in storage pools, you must do two things:
You can run expiration processing automatically or by command. See Running Expiration Processing to Delete Expired Files.
For a storage pool associated with a library that has more than one drive, the reclaimed data is moved to other volumes in the same storage pool. For a storage pool associated with a library that has only one drive, the reclaimed data is moved to volumes in another storage pool that you must define, called a reclamation storage pool. See Reclaiming Volumes in a Storage Pool with One Drive.
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 with the DELETE VOLUME command. See Reclaiming Space in Sequential Access Storage Pools.
For automated libraries, see Managing Server Requests for Media.
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.
When you back up the database or export server information, TSM records information about the volumes used for these operations in the volume history file. TSM will not allow you to reuse these volumes until you delete the volume information from the volume history file. To reuse volumes that have previously been used for database backup or export, use the DELETE VOLHISTORY command. For information about the volume history file, see Saving the Volume History File.
When you define a storage pool, you must specify the maximum number of scratch volumes that the storage pool can use. TSM automatically requests a scratch volume when needed. When the number of scratch volumes that TSM is using for the storage pool exceeds the maximum number of scratch volumes specified, the storage pool can run out of space.
Ensure that you set the maximum number of scratch volumes high enough for the expected usage. When you exceed this number, you can do one or both of the following:
For automated libraries, see also Maintaining a Supply of Scratch Volumes in an Automated Library.
For libraries with WORM drives, prevent cancellation of data storage transactions by maintaining a supply of scratch or new private volumes in the library. Canceled transactions can cause wasted WORM media. TSM cancels (rolls back) a transaction if volumes, either private or scratch, are not available to complete the data storage operation. After TSM begins a transaction by writing to a WORM volume, the written space on the volume cannot be reused, even if the transaction is canceled.
For example, if a client starts to back up data and does not have sufficient volumes in the library, TSM cancels the backup transaction. The WORM volumes to which TSM had already written for the canceled backup are wasted because the volumes cannot be reused. Suppose that you have WORM platters that hold 2.6GB each. A client starts to back up a 12GB file. If TSM cannot acquire a fifth scratch volume after filling four volumes, TSM cancels the backup operation. The four volumes that TSM already filled cannot be reused.
To minimize cancellation of transactions, do the following: