Administrator's Guide


Maintaining the Volume Inventory

With TSM, you maintain your volume inventory by performing the following tasks:

Controlling Access to Volumes

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 unavailable to TSM, you can change the access mode of the volumes. For example, use the UPDATE VOLUME command with ACCESS=UNAVAILABLE. 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.

Reusing Tapes in Storage Pools

To reuse tapes in TSM storage pools, you must do two things:

Expiration Processing of Client Files

Expiration processing deletes from the TSM database information about any client files that are no longer valid according to the policies you have set. For example, suppose four backup versions of a file exist in TSM server storage, and only three versions are allowed in the backup policy (the management class) for the file. Expiration processing deletes information about the oldest of the four versions of the file. The space that the file occupied in the storage pool can then be reclaimed.

You can run expiration processing automatically or by command. See Running Expiration Processing to Delete Expired Files.

Reclamation

You can have TSM reclaim volumes that pass a reclamation threshold, a percentage of unused space on the volume. The reclamation threshold is set for each storage pool. See Reclaiming Space in Sequential Access Storage Pools.

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.

Reusing Volumes Used for Database Backups and Export Operations

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.

Note:If your server is licensed for the DRM product, the volume information is automatically deleted during MOVE DRMEDIA command processing. For additional information about DRM, see Chapter 21, Using Tivoli Disaster Recovery Manager.

Maintaining a Supply of Scratch Volumes

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.

Maintaining a Supply of Volumes in a WORM Library

For libraries with WORM drives, try to 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:

For libraries with WORM drives, try to prevent data storage transactions from being canceled 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. Once TSM begins a transaction by writing to a WORM volume, that written space on the volume cannot be reused, even if the transaction is canceled. For example, if a client starts to back up data but TSM cannot complete the backup because of a lack of 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 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:

  1. Ensure that you have enough volumes available in the library to handle expected client operations such as backup.

  2. Verify that you set the maximum number of scratch volumes for the storage pool associated with the library to a high enough number.

  3. Check in to the library enough scratch or private volumes to handle the expected load.

If your clients tend to store files of smaller sizes, 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.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]