Administrator's Guide

Backup and Recovery Scenarios

This section presents scenarios for protecting and recovering an ADSM server. You can modify the procedures to meet your needs.

DRM can help you track your onsite and offsite volumes and query the ADSM server and generate a current, detailed disaster recovery plan for your installation.

These scenarios assume a storage hierarchy consisting of:

The default random access storage pools (BACKUPPOOL, ARCHIVEPOOL, and SPACEMGPOOL)
TAPEPOOL, a tape storage pool

Protecting Your Database and Storage Pool

A company's standard procedures include the following:

Perform reclamation of its copy storage pool, once a week. Reclamation for the copy storage pools is turned off at other times.

Note:

In a copy storage pool definition, the REUSEDELAY parameter delays volumes from being returned to scratch or being reused. The value should be set high enough to ensure that the database can be restored to an earlier point in time and that the database references to files in the storage pool is still valid. For example, a user may want to retain database backups for seven days and, therefore, sets REUSEDELAY to 7.

Back up its storage pools every night.
Perform a full backup of the database once a week and incremental backups on the other days.
Ship the database and copy storage pool volumes to an offsite location every day.

To protect client data, the administrator does the following:

Creates a copy storage pool named DISASTER-RECOVERY. Only scratch tapes are used, and the maximum number of scratch volumes is set to 100. The copy storage pool is defined by entering:
```
define stgpool disaster-recovery tapeclass pooltype=copy
maxscratch=100
```
Performs the first backup of the primary storage pools.
Note: The first backup of a primary storage pool is a full backup and, depending on the size of the storage pool, could take a long time.

Defines schedules for the following daily operations:

Incremental backups of the primary storage pools each night by issuing:

backup stgpool backuppool disaster-recovery maxprocess=2

backup stgpool archivepool disaster-recovery maxprocess=2

backup stgpool spacemgpool disaster-recovery maxprocess=2

backup stgpool tapepool disaster-recovery maxprocess=2

These commands use multiple, parallel processes to perform an incremental backup of each primary storage pool to the copy pool. Only those files for which a copy does not already exist in the copy pool are backed up.
Note: Migration should be turned off during the rest of the day. You could add a schedule to migrate from disk to tape at this point. In this way, the backups are done while the files are still on disk.

Change the access mode to OFFSITE for volumes that have read-write or read-only access, are onsite, and are at least partially filled. This is done by entering:
```
update volume * access=offsite location='vault site info'
wherestgpool=disaster-recovery whereaccess=readwrite,readonly
wherestatus=filling,full
```

Back up the database by entering:

backup db type=incremental devclass=tapeclass scratch=yes

Does the following operations nightly after the scheduled operations have completed:
1. Backs up the volume history, device configuration, and server options.
2. Moves the volumes marked offsite, the database backup volumes, volume history files, device configuration files, and server options to the offsite location.
3. Identifies offsite volumes that should be returned onsite by using the QUERY VOLUME command:
```
query volume stgpool=disaster-recovery access=offsite status=empty
```
  These volumes, which have become empty through expiration, reclamation, and file space deletion, have waited the delay time specified by the REUSEDELAY parameter. The administrator periodically returns outdated backup database volumes. These volumes are displayed with the QUERY VOLHISTORY command and can be released for reuse with the DELETE VOLHISTORY command.
Brings the volumes identified in step 3 onsite and updates their access to read-write.

Recovering to a Point in Time from a Disaster

In this scenario, the processor on which ADSM resides, the database, and all onsite storage pool volumes are destroyed by fire. An administrator restores the server to the point in time of the last backup.

DRM can help you do these steps.

Do the following:

Install the ADSM server on the replacement processor with the same server options and the same size database and recovery log as on the destroyed system. For example, to initialize the database and recovery log, enter:
```
> dsmserv format 1 log1 1 dbvol1
```
Move the latest backup and all of the DISASTER-RECOVERY volumes onsite from the offsite location.
Note: Do not change the access mode of these volumes until after you have completed step 7.
If a current, undamaged volume history file exists, save it.
Restore the volume history and device configuration files and the server options.
Restore the database from the latest backup level by issuing the DSMSERV RESTORE DB command (see "Recovering by Using Database and Storage Pool Backups").

Change the access mode of all the existing primary storage pool volumes in the damaged storage pools to DESTROYED by entering:

update volume * access=destroyed wherestgpool=backuppool

update volume * access=destroyed wherestgpool=archivepool

update volume * access=destroyed wherestgpool=spacemgpool

update volume * access=destroyed wherestgpool=tapepool

Issue the QUERY VOLUME command to identify any volumes in the DISASTER-RECOVERY storage pool that were onsite at the time of the disaster. Any volumes that were onsite would have been destroyed in the disaster and could not be used for restore processing. Delete each of these volumes from the database by using the DELETE VOLUME command with the DISCARDDATA option. Any files backed up to these volumes cannot be restored.

Change the access mode of the remaining volumes in the DISASTER-RECOVERY pool to READWRITE by entering:

update volume * access=readwrite wherestgpool=disaster-recovery

Note:

Clients can get files from ADSM at this point. If a client tries to get a file that was stored on a destroyed volume, the retrieval request goes to the copy storage pool. In this way, clients can access their files without waiting for the primary storage pool to be restored. When you update volumes brought from offsite to change their access, you greatly speed recovery time.

Define new volumes in the primary storage pool so the files on the damaged volumes can be restored to the new volumes. The new volumes also allow clients to backup, archive, or migrate files to the server. You do not need to perform this step if you use only scratch volumes in the storage pool.
Restore files in the primary storage pool from the copies located in the DISASTER-RECOVERY pool by entering:
```
restore stgpool backuppool maxprocess=2
```
```
restore stgpool archivepool maxprocess=2
```
```
restore stgpool spacemgpool maxprocess=2
```
```
restore stgpool tapepool maxprocess=2
```
These commands use multiple parallel processes to restore files to primary storage pools. After all the files have been restored for a destroyed volume, that volume is automatically deleted from the database. See "When a Storage Pool Restoration Is Incomplete" for what to do if one or more volumes cannot be fully restored.
To ensure against another loss of data, immediately back up all storage volumes and the database. Then resume normal activity, including weekly disaster backups and movement of data to the offsite location.

Recovering a Lost or Damaged Storage Pool Volume

If a company makes the preparations described in "Protecting Your Database and Storage Pool" it can recover from a media loss by using ADSM features.

In this scenario, an operator inadvertently destroys a tape volume (DSM087) belonging to the TAPEPOOL storage pool. An administrator performs the following actions to recover the data stored on the destroyed volume by using the offsite copy storage pool:

Determine the copy pool volumes that contain the backup copies of the files that were stored on the volume that was destroyed by entering:
```
restore volume dsm087 preview=volumesonly
```
This command produces a list of offsite volumes that contain the backed up copies of the files that were on tape volume DSM087.
Set the access mode of the copy volumes identified as UNAVAILABLE to prevent reclamation.
Note: This precaution prevents the movement of files stored on these volumes until volume DSM087 is restored.
Bring the identified volumes to the onsite location and set their access mode to READWRITE.
Restore the destroyed files by entering:
```
restore volume dsm087
```
This command sets the access mode of the DSM087 to DESTROYED and attempts to restore all the files that were stored on volume DSM087. The files are not actually restored to volume DSM087, but to another volume in the TAPEPOOL storage pool. All references to the files on DSM087 are deleted from the database and the volume itself is deleted from the database.
Set the access mode of the volumes used to restore DSM087 to OFFSITE using the UPDATE VOLUME command.
Return the volumes to the offsite location.

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