IBM TSM - Migration
Migration helps control the amount of free space within a storage pool, and can be used to move data to its final (or more permanent) location. High and low migration thresholds can be defined for each primary storage pool in the hierarchy. The thresholds tell Tivoli Storage Manager when to move data from one storage pool to another. The default values for a newly created storage pool are 90 percent (HIghmig) and 70 percent (LOwmig). Copy storage pools do not have migration thresholds.
When the amount of data in a storage pool reaches the high threshold, a Tivoli Storage Manager server process is automatically initiated, to move client data to the next storage pool in the hierarchy, until the first storage pool reaches the low threshold. When a migration process starts in this way, the objective is to clear as much space in the originating pool as quickly as possible.
Tivoli Storage Manager picks the client node whose data occupies the most space in that storage pool and migrates the largest filespace of that client data. It then picks the next client node that has the most data, and migrates that. The migration continues until the amount of data drops to, or below, the low threshold. Migration is always done at the filespace level of granularity. This method not only clears space quickly but also helps keep a client’s data close together in the hierarchy. In turn, the number of media mounts required during client data restoration is reduced.
For random access storage pools only, you can specify the number of processes that are spawned for migrating files from each storage pool. The MIGPRocess parameter is optional, and defaults to 1. You can set a migration process value equal to or less than the number of drives in the next storage pool you are migrating to; the migration processes are performed in parallel to improve data transfer rates. Note that if you have two tape drives in the target storage pool, and if you have set MIGPRocess to 2, any other requests for the tape devices will be denied until the migration process is completed.
The way a migration process chooses files for migration is also influenced by the disk caching attribute (Cache), and the migration delay value (MIGDelay). You can specify the number of days to delay migration for files in a storage pool, ensuring that files stay in a pool for a minimum number of days. Setting MIGDelay may require a larger capacity for your disk storage pool to be able to keep the files there. The benefit is that required files can be restored faster if they have not yet been migrated from the disk storage pool to a slower device.
At some point in time, you may wish to force migration from a disk pool to a tape pool. Rather than just wait until a disk pool reaches its high migration threshold, a migration process can be initiated at any time. One reason for manually initiating a migration process is that migration during client backup may reduce performance because of the additional I/O. If there are a large number of clients backing up simultaneously, it is a best practice to give them an empty disk pool large enough to contain a typical incremental backup, so that migration is not triggered.
There are two ways to initiate a migration: * Update the storage pool, modifying the values of HIghmig, LOwmig, or both. * Use the migrate stgpool command in Tivoli Storage Manager V5.3.
Before Tivoli Storage Manager V5.3, migration could only be forced by updating the HIghmig or LOwmig, (or both) parameters for the storage pool. Usually, an administrative scheduled command would update the values to initiate the migration. Later, another scheduled administrative command would reset the values to the original ones. A typical use would be to set HIghmig to 10 percent and LOwmig to 0. Unless the storage pool was less than 10 percent full, these settings would drain the pool completely. Some time later, you must remember to reset the values, otherwise the storage pool is effectively only 10 percent of its real size.
With Tivoli Storage Manager V5.3, the migrate stgpool command migrates a storage pool with a single command. The command takes a value for LOwmig as well as a DUration parameter in minutes. After DUration minutes have elapsed, the original value of LOwmig is reset. For sequential storage pools, an optional REClaim parameter can be passed. If the REClaim parameter is set to “yes”, reclamation of the storage pool will be attempted prior to migration.