This section explains how to recover by using backups of the database and storage pools. Figure 62 shows the situation presented in the two scenarios in this section: an installation has lost its server, including the database and recovery log, and its onsite storage pools.
Figure 62. Recovery from a Disaster
The following topics are included:
To perform a restore, you should have the following information, preferably stored offsite (see Figure 62):
|
| DRM can query the ADSM server and generate a current, detailed disaster
recovery plan for your installation.
|
Point-in-time recovery is normally used for situations such as disaster recovery or to remove the effects of errors that can cause inconsistencies in the database.
Here is the procedure for restoring the database:
> dsmserv format 1 log1 1 dbvol1
Attention: Do not start the server until after you restore the database (the next step). Starting the server before the restore would destroy any existing volume history files.
> dsmserv restore db todate=04/19/1996
ADSM does the following:
| Note: | If the volume history file is not available, you must mount tape volumes in the correct order or specify their order on the DSMSERV RESTORE DB command. |
From the old volume history information (generated by the QUERY VOLHISTORY command) you need a list of all the volumes that were reused (STGREUSE), added (STGNEW), and deleted (STGDELETE) since the original backup. Use this list to perform the following steps.
This process identifies files recorded in the database that can no longer be found on the volume. If a copy of the file is in a copy storage pool, the file on the audited volume is marked as damaged. Otherwise, the file is deleted from the database and is lost.
Some files may be lost if they were moved since the backup (due to migration, reclamation, or move data requests) and the space occupied by those files has been reused. You can minimize this loss by using the REUSEDELAY parameter when defining or updating sequential access storage pools. This parameter delays volumes from being returned to scratch or being reused.
By backing up your storage pool and your database, you reduce the risk of losing data. To further minimize loss of data, you can:
In this way the backup volumes are preserved and are not reused or mounted until they are brought onsite. Ensure that you mark the volumes as OFFSITE before you back up the database.
Attention: You can avoid having to mark volumes as offsite or physically move volumes:
If your old volume history file shows that any of the copy storage pool volumes needed to restore your storage pools have been reused (STGREUSE) or deleted (STGDELETE), you may not be able to restore all your files. You can avoid this problem by including the REUSEDELAY parameter when you define your copy storage pools.
After a restore, the volume inventories for ADSM and for your tape management system may be inconsistent. For example, after a database backup, a new volume is added to ADSM. The tape management system inventory records the volume as belonging to ADSM. If the database is restored from the backup, ADSM has no record of the added volume, but the tape management system does. You must synchronize these inventories.
If you are doing a point-in-time restore and a volume history file is not available, you must enter the volume names in the DSMSERV RESTORE DB command in the sequence in which they were written to. First, however, issue the DSMSERV DISPLAY DBBACKUPVOLUME command to read your backup volumes and display the information needed to arrange them in order (backup series, backup operation, and volume sequence):
> dsmserv display dbbackupvolume devclass=tapeclass volumenames=dsm012,dsm023,dsm037,dsm038,dsm058,dsm087
For example, the most recent backup series consists of three operations:
You would issue three commands in the following order:
> dsmserv restore db volumenames=dsm023,dsm037,dsm087 devclass=tapeclass commit=no
> dsmserv restore db volumenames=dsm012 devclass=tapeclass commit=no
> dsmserv restore db volumenames=dsm038,dsm058 devclass=tapeclass commit=no
Attention: If the original database or recovery log volumes are available, you issue only the DSMSERV RESTORE DB command. However, if those volumes have been lost, you must first issue the DSMSERV FORMAT command to initialize the database and recovery log, then issue the DSMSERV RESTORE DB command.
The following example shows the importance of storage pool backups with a point-in-time restore. In this example, the storage pool was not backed up with the BACKUP STGPOOL command.
The server places Client B's files in the location that contained Client A's files prior to the migration.
If rollforward recovery had been used, the database would have been rolled forward to 3:30 p.m. when the server went down, and neither Client A's files nor Client B's files would have been lost. If a point-in-time restore of the database had been performed and the storage pool had been backed up, Client A's files would not have been deleted by the volume audit and could have been restored with a RESTORE VOLUME or RESTORE STGPOOL command. Client B's files would still have been lost, however.
You can use rollforward recovery to restore a database to its most current state if:
To restore the database to its most current state, enter:
> dsmserv restore db
Attention: If the original database or recovery log volumes are available, you issue only the DSMSERV RESTORE DB command. However, if those volumes have been lost, you must first issue the DSMSERV FORMAT command to initialize the database and recovery log, then issue the DSMSERV RESTORE DB command.
| Note: | Rollforward recovery does not apply if all recovery log volumes are lost. However, with the server running in rollforward mode, you can still perform point-in-time recovery in such a case. |
An administrator can recreate files in a primary storage
pool using duplicate copies in copy storage pools by issuing the RESTORE
STGPOOL command. The files must have been copied to the copy storage
pools by using the BACKUP STGPOOL command.
| Task | Required Privilege Class |
|---|---|
| Restoring storage pools | System, unrestricted storage, or restricted storage |
The RESTORE STGPOOL command restores specified primary storage pools that have files with the following problems:
When you restore a storage pool, be prepared to provide the following information:
See "Correcting Damaged Files" and "Backup and Recovery Scenarios" for examples of using the RESTORE STGPOOL command.
When you restore a storage pool, ADSM determines which files are in the storage pool being restored, according to the ADSM database. Using file copies from a copy storage pool, ADSM restores the files that were in the storage pool to the same or a different storage pool.
| Cached Files: | Cached copies of files in a disk storage pool are never restored. References to any cached files that have been identified as having read errors or cached files that reside on a destroyed volume will be removed from the database during restore processing. |
The RESTORE STGPOOL command with the PREVIEW=YES parameter can be used to identify volumes that contain damaged primary files. During restore processing, a message is issued for every volume in the restored storage pool that contains damaged, noncached files. To identify the specific files that are damaged on these volumes, use the QUERY CONTENT command.
After the files are restored, the old references to these files in the primary storage pool are deleted from the database. This means that ADSM now locates these files on the volumes to which they were restored, rather than on the volumes on which they were previously stored. If a destroyed volume becomes empty because all files have been restored to other locations, the destroyed volume is automatically deleted from the database.
The RESTORE STGPOOL command generates a background process that can be canceled with the CANCEL PROCESS command. If a RESTORE STGPOOL background process is canceled, some files may have already been restored prior to the cancellation. To display information about background processes, use the QUERY PROCESS command.
The RESTORE STGPOOL command may be run in the foreground on an administrative client by issuing the command with the WAIT=YES parameter.
When restoring to a primary storage pool that has collocation enabled, the server restores files by client node and client file space. This process preserves the collocation of client files. However, if the copy storage pool being used to restore files does not have collocation enabled, restore processing can be slow.
If you need to use a copy storage pool that is not collocated to restore files to a primary storage pool that is collocated, you can improve performance by:
For the random access pool, set the target storage pool as the next storage pool. Adjust the migration threshold to control when migration occurs to the target storage pool.
The restoration of a storage pool volume may be incomplete. Use the QUERY CONTENT command to get more information on the remaining files on volumes for which restoration was incomplete. The restoration may be incomplete for one or more of the following reasons:
Also, you can prevent reclamation processing for your copy storage pools by setting the RECLAIM parameter to 100 with the UPDATE STGPOOL command.
