Administrator's Guide


Backing Up Storage Pools


Task Required Privilege Class
Define, back up, or restore storage pools

Restore volumes

System, unrestricted storage, or restricted storage (only for those pools to which you authorized)
Update volumes System or operator
Query volumes or storage pools Any administrator

You can create backup copies of client files that are stored in primary storage pools. The backup copies are stored in copy storage pools, which you can use to restore the original files if they are damaged, lost, or unusable. Primary storage pools should be backed up incrementally each day to the same copy storage pool. Backing up to the same copy storage pool ensures that files do not need to be recopied if they have migrated to the next pool.

Attention: You can back up multiple primary storage pools to one copy storage pool. If multiple copies are necessary, you can also back up a primary storage pool to multiple copy storage pools. However, you should back up the entire primary storage pool hierarchy to the same copy storage pool for easier management of storage volumes.

Figure 68. Copy Storage Pools

Copy Storage Pools

If you schedule storage pool backups and migrations and have enough disk storage, you can copy most files from the disk storage pool before they are migrated to tape and thus avoid unnecessary mounts. Here is the sequence:

  1. Clients back up or archive data to disk

  2. You issue the BACKUP STGPOOL command to back up the primary storage pools to copy storage pools

  3. Data migrates from disk storage pools to primary tape storage pools

Backing up storage pools requires an additional 200 bytes of space in the database for each file copy. As more files are added to the copy storage pools, reevaluate your database size requirements.

Because the copies are made incrementally, you can cancel the backup process. Reissuing the BACKUP STGPOOL command lets the backup continue from the spot the backup was canceled. For example, to back up the ARCHIVEPOOL primary pool to the DISASTER-RECOVERY copy pool, enter:

backup stgpool archivepool disaster-recovery

You can define schedules to begin incremental backups of files in the primary storage pools. For example, to back up the BACKUPPOOL, ARCHIVEPOOL, and the TAPEPOOL every night, schedule the following commands:

backup stgpool backuppool disaster-recovery maxprocess=4
 
backup stgpool archivepool disaster-recovery maxprocess=4
 
backup stgpool tapepool disaster-recovery maxprocess=4

These commands use four parallel processes to perform an incremental backup of each primary storage pool to the copy pool. The only files backed up to the DISASTER-RECOVERY pool are files for which a copy does not already exist in the copy storage pool. See Chapter 15, Automating Server Operations for information about scheduling commands.

Notes:

  1. Set the MAXPROCESS parameter to the number of mount points or drives that can be dedicated to this operation.

  2. Backing up storage pools requires additional space on the TSM database.

  3. If a copy is to be made in a copy storage pool and a copy already exists with the same insertion date, no action is taken.

  4. Files in a copy storage pool do not migrate to another storage pool.

  5. When a disk storage pool is backed up, copies of files that remain on disk after being migrated to the next storage pool (cached files) are not backed up.

For recovery scenarios that involve backed up copies of storage pools, see Recovering to a Point-in-Time from a Disaster and Recovering a Lost or Damaged Storage Pool Volume.

Delaying Reuse of Sequential Access Volumes

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 been expired, deleted, or moved from the volume. When you delay reuse of such volumes and they no longer contain any files, they enter the pending state. Volumes remain in the pending state for as long as specified with the REUSEDELAY parameter for the storage pool to which the volume belongs.

Delaying reuse of volumes can be helpful under certain conditions for disaster recovery. When TSM expires, deletes, or moves files from a volume, the files are not actually erased from the volumes: the database references to these files are removed. Thus the file data may still exist on sequential volumes if the volumes are not immediately reused.

If a disaster forces you to restore the TSM database using a database backup that is old or is not the most recent backup, some files may not be recoverable because TSM cannot find them on current volumes. However, the files may exist on volumes that are in pending state. You may be able to use the volumes in pending state to recover data by doing the following:

  1. Restore the database to a point-in-time prior to file expiration.

  2. Use a primary or copy storage pool volume that has not been rewritten and contains the expired file at the time of database backup.

If you back up your primary storage pools, set the REUSEDELAY parameter for the primary storage pools to 0 to efficiently reuse primary scratch volumes. For your copy storage pools, you should delay reuse of volumes for as long as you keep your oldest database backup.

For an example of using database backup and delaying volume reuse, see Protecting Your Database and Storage Pool. For information about expiration, see Running Expiration Processing to Delete Expired Files.


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