You can back up primary storage pools to copy storage pools to improve data availability. This action protects against the possibility of media failure. With copy storage pools you can
take incremental backups of clients while the server is operational and available to clients.
The administrator decides the storage pools to back up, and also schedules these backups by using the central scheduling feature of Tivoli Storage Manager. You should run the storage pool backups at a time that is convenient for the business. Copy storage pools provide the following support
The administrator decides the storage pools to back up, and also schedules these backups by using the central scheduling feature of Tivoli Storage Manager. You should run the storage pool backups at a time that is convenient for the business. Copy storage pools provide the following support
- You can switch to a duplicate copy automatically if the primary file is damaged.
- You can back up primary stgpools without interruption of service.
- You can restore individual volumes within a storage pool to recover from a media failure.
restore volume volumename
- Restore all damaged volumes within a storage pool to recover from a complete loss of a storage pool.
restore stgpool primarystgpoolname
- You can identify removable media volumes that contain storage pool backup data to send to an off-site location for disaster recovery purposes. Provide management for the volumes that are stored off-site for disaster recovery protection. Address the issues of file expiration, volume reclamation, and volume rotation. Identify the volumes that are to return to the on-site location if you need to recover from a major disaster or from loss of a few volumes at the on-site location.
- Automatically switch to a duplicate copy if the primary file is damaged. If you cannot obtain the primary file, use the duplicate copy automatically, if one is available.
Copy Storage pools Overview
One primary pool can use multiple copy storage pools. You might have many copy storage pools for each primary storage pool, not only two or three backup copies. Each copy pool requires additional database and storage pool space, a potentially important consideration.
By supporting multiple copy storage pools, Tivoli Storage Manager supports both media and disaster recovery by physically separating these copies. This separation reduces the risk of losing data as a result of a disaster.
You create multiple backup copies of a primary pool by initiating the backup of the primary storage pool for each copy pool. The incremental backup is done for each copy storage pool. The files are copied only if they are not already in that copy or if the copy in the copy pool has a different insertion date. A different insertion date refers to the case of a file changing since it is last copied into the copy pool.
Also Read: SQL commands to query TSM Server
Disaster recovery is the reason to provide copy storage pools with off-site volumes. Off-site volumes in the disaster recovery copy storage pool are never automatically used by Tivoli Storage Manager. The volumes in this copy pool are marked with the access mode of OFFSITE to ensure that Tivoli Storage Manager does not request a mount of the volume. The off-site volumes in the disaster recovery copy storage pool are stored off-site with the database backup to ensure that you can recover the Tivoli Storage Manager environment if a disaster occurs.
You receive an error message when trying to access files from a copy storage pool that contains off-site volumes only. You can move the volume on-site temporarily and recover the files from volumes that belong to the disaster recovery storage pool.
You can use the define stgpool command with pooltype=copy parameter to define a copy storagepools. It is recommended to use only tape device class for copy storagepool, so that you can send them to offsite for disaster protection. You can specify andy deviceclass except DISK. You can also FILE device class but since you cannot send them to offsite daily, it is not recommeded.
define stgpool copystgpool devc=lto6 pooltype=copy maxscr=999
How to backup primary stgpool to copy stgpools
If migration for a storage pool starts during a storage pool backup, some files may be migrated before they are backed up. You may want to back up storage pools that are higher in the migration hierarchy before backing up storage pools that are lower.
backup stgpool primarystgpool copystgpool maxprocess=1 preview=no|yes|volumesonly
Preview parameter specifies if you want to preview but not perform the backup. The preview displays the number of files and bytes to be backed up and a list of the primary storage pool volumes that you must mount. This parameter is optional. The default is NO. Possible values are:
No - Specifies that the backup is done.
VOLumesonly - Specifies that you want to preview the backup only as a list of the volumes that must be mounted. This choice requires the least processing time. The VOLUMESONLY option is valid only for storage pools associated with a sequential-access device class.
Managing Copy Storage Pool Volumes
On the tapes that are used for the copy storage pool for off-site disaster recovery, set the status as not available to Tivoli Storage Manager. If you use DRM techniques, it will be automatically changed to OFFSITE when you run the move drmedia command.
But If you are not using DRM, you have to update volumes manually. To change the status, use the update volume command by specifying ACCESS = OFFSITE. Tivoli Storage Manager does not issue mount requests for off-site volumes.
You can update each volume that is used during the backup, one at a time
UPDate Volume Volname ACCess=Offsite Location=“Vault”
Or you can use the following command to update all volumes used with one command
update volume * access=offsite location=“off-site location” wherestgpool=off-site whereaccess=readwrite,readonly wherestatus=filling,full
You can use the following command to create a list of volumes to send off-site
query media * stg=* wherestgpool=offsite whereaccess=readwrite,readonly wherestatus=filling,full
Also Read: What is Cloud Container Storagepool ?
After some days, due to the retention settings data on the copy storagepool volumes also expired and those volumes should be reused scratch again. The process of reclaiming offsite storagepools is called Offsite Reclamation. To obtain a list of empty off-site volumes, issue the following command
After some days, due to the retention settings data on the copy storagepool volumes also expired and those volumes should be reused scratch again. The process of reclaiming offsite storagepools is called Offsite Reclamation. To obtain a list of empty off-site volumes, issue the following command
query volume * access=offsite status=empty stg=OFFSITE
To bring these identified volumes on-site and to update their access to read/write, issue the following command
update volume * access=readwrite location=“Onsite location” wherestgpool=off-site whereaccess=offsite wherestatus=empty
Importance of using REUSEDELAY Parameter in Copy storage pools
When you define or update a sequential access storage pool, you can use the REUSEDELAY parameter. This parameter specifies the number of days that must elapse before a volume can be reused or returned to scratch status after all files have expired, deleted, or moved from the volume. If REUSEDELAY is set to 0, you might lose data
Delay the reuse of any reclaimed volumes that are in copy storage pools for as long as you keep your oldest database backup. Delaying reuse can help you to recover data under certain conditions during recovery from a disaster. You can use the following command to update this
update stgpool copystgpool reusedelay=7
So, from the above command copy stgpool volumes which become empty after few days will not be changed to SCRATCH status for 7 days. These volumes will have a PENDING status. This number of days should match to the TSM Database backup expire days.
0 Comment to "10.1 Protecting Primary Storage pools with Copy Storage pools"
Post a Comment