![]() |
![]() |
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 are 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.
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.
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:
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 17, Automating Server Operations for information about scheduling commands.
Notes:
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.
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 files are expired, deleted, or moved from a volume, they 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.
A disaster may force you to restore the database using a database backup that is not the most recent backup. In this case, some files may not be recoverable because the server 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:
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.