IBM TSM - Reclamation
Reclamation is a server process that consolidates data and free space on tape (or optical) volumes in sequential storage pools. Over time, versions of backed-up files expire, or perhaps files are deleted from client file systems. It is common for tape volumes to contain files that will expire on different dates. When the expiration process occurs, expired and deleted files are marked as no longer required, and the tape volumes on which these files are stored now have empty space where the files physically resided.
Over time, as more and more files are expired from a tape volume, its active data spaces become fragmented by the increasing empty space. Fragmentation on tapes or optical disks causes increased read times due to the need to skip over the empty spaces. Similarly, restores take longer. The total number of volumes required is also higher than it needs to be. It is not possible to go back and rewrite new data in the empty spaces — sequential media can only be written from the beginning to the end. Once a sequential volume has been completely written one time, Tivoli Storage Manager will not write to it again, until it becomes totally empty.
The amount of empty space on a sequential volume is presented as the percentage of reclaimable space on the volume. Rather than wait until a volume becomes completely empty (which may never happen if data on the volume is active on the client), the empty space can be “reclaimed”. Reclamation means moving the active data to another volume in the same storage pool. Only volumes that have a status of “scratch” or “filling” can be used to store the moved data (similarly, onsite volumes can only be reclaimed after they become “full”). When all the data is moved from the original tape to another, the original becomes empty, and is typically returned to a status of “scratch”. A scratch tape can be re-used for any function for which the server requires a volume.
The reclamation threshold is set on sequential storage pools via the REClaim parameter. The default value for a new storage pool is 60 percent, which can be over-ridden when the pool is created, or subsequently changed. When the reclamation value is reached for a particular sequential volume (that is, when the percentage of reclaimable data on the tape reaches the RECLAIM value), a reclamation process starts automatically for that volume. Having a reclamation process start automatically may not be desirable — the reclamation process is very device-intensive, and normally requires at least two available drives in the library (one to read, one to write). Other critical Tivoli Storage Manager operations (for example, a client restore) might be delayed or refused if all drives were engaged in reclamation. It is usually more convenient and efficient to schedule reclamation.
To prevent reclamation of volumes from happening automatically, set the value of REClaim on the storage pool to 100 percent. Then, at a suitable time, the reclamation process can be initiated using the reclaim stgpool command on Tivoli Storage Manager V5.3 or updating the storage pool to change the REClaim value. If reclamation is scheduled using the latter method, you must remember to reset the value after a suitable period. When setting the value of REClaim to start reclamation, we recommend that you specify a value of 50 percent or greater so that files stored on two volumes can be combined onto a single output volume.
For offsite volumes, reclamation can occur regardless of whether the volume has ever been filled. An offsite volume is eligible for reclamation when the percentage of unused space on the volume is greater than the reclaim parameter value. The unused space includes both space that has never been used on the volume and space that has become empty because of file deletion. To avoid excessive reclamation on copy storage pools, it is also recommended to disable reclamation, except for certain defined periods, as described in the previous paragraph.
Reclamation of offsite volumes
Tivoli Storage Manager cannot physically move the data from one of these volumes to another because they are in an offsite vault, not available in the library. Tivoli Storage Manager manages reclamation for an offsite copy pool by obtaining the active files from a primary storage pool or from an onsite volume of a copy pool. These files are then written to a new volume in the copy pool, and the database is updated. A message is then issued that the offsite volume was reclaimed and is now ready for retrieval from the vault. The new volume will be moved to the offsite location, and the offsite volume, will be moved back to the onsite scratch pool.
Take care when reclaiming offsite copy storage pool volumes. If a disaster occurs, there is a potential issue: if the reclaimed volumes have already been returned to the scratch pool and the new volume has not yet been taken offsite, we have lost the offsite backup. To avoid potential problems such as this, sequential storage pool can have the delay reuse period configured. REUsedelay specifies the number of days that must elapse before volumes can be rewritten or returned to the scratch pool after all files are deleted.
The easiest way to avoid this situation is to control when reclamation will occur by scheduling. Before scheduling reclamation, ensure that you have performed a backup of all onsite storage pools to their offsite copy pools, then perform a database backup so that the offsite database copy list all of the volumes in their new locations. The reuse delay period defined on the storage pools must be long enough to ensure that the reclaimed volumes do not return to the scratch pool before another database backup is made.