This section explains how to recover by using backups of the database and storage pools. Figure 69 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 69. Recovery from a Disaster
The following topics are included:
To perform a restore, you should have the following information, preferably stored offsite (see Figure 69):
| DRM can query the TSM 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.
You can use either full and incremental backups or snapshot database backups to restore a database to a point-in-time.
Here is the procedure for restoring the database:
You may need to modify the device configuration file based on the hardware available at the recovery site. For example, if the recovery site has 3590 devices and at the disaster site has 3480 devices, the device class definitions would have to be modified. For more information, see Updating the Device Configuration File.
A sample JCL:
//TIVSM JOB MSGLEVEL=(1,1), // REGION=40M,TIME=1440,CLASS=A,MSGCLASS=H //*------------------------------------------------------------- //SERVER EXEC PGM=DSMSERV,DYNAMNBR=300 // PARM='/FORMAT 1 SERVER0.RLOG 1 SERVER0.DB01' //OPT DD DSN=SERVER.OPTIONS,DISP=MOD //DSMAMENG DD DSN=TIVSM.SANRMSG(ANRMENU),DISP=SHR //HLPAMENG DD DSN=TIVSM.SANRHLP(ANRHENU),DISP=SHR //IDL DD DSN=TIVSM.SANRIMG(ANRIDL),DISP=SHR //DSK DD DSN=TIVSM.DISKLOG,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSTERM DD SYSOUT=* /* //
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.
A sample JCL:
//TIVSM JOB MSGLEVEL=(1,1), // REGION=40M,TIME=1440,CLASS=A,MSGCLASS=H //*------------------------------------------------------------- //SERVER EXEC PGM=DSMSERV,DYNAMNBR=300 // PARM='/RESTORE DB DEV=CARTRIDGE VOL=FILE:DD:TAPES' //OPT DD DSN=SERVER.OPTIONS,DISP=MOD //DSMAMENG DD DSN=TIVSM.SANRMSG(ANRMENU),DISP=SHR //HLPAMENG DD DSN=TIVSM.SANRHLP(ANRHENU),DISP=SHR //IDL DD DSN=TIVSM.SANRIMG(ANRIDL),DISP=SHR //DSK DD DSN=TIVSM.DISKLOG,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSTERM DD SYSOUT=* //TAPES DD * TAPE01 TAPE02 TAPE03 TAPE04 /* //
TSM 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 utility. |
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 rest of this procedure.
It may also be necessary to update the device configurations in the restored database.
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.
Notes:
To 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 TSM and for your tape management system may be inconsistent. For example, after a database backup, a new volume is added to TSM. The tape management system inventory records the volume as belonging to TSM. If the database is restored from the backup, TSM has no record of the added volume, but the tape management system does. You must synchronize these inventories.
You can use either full and incremental backups or snapshot database backups to restore a database to a point-in-time.
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 utility in the sequence in which they were written to. First, however, issue the DSMSERV DISPLAY DBBACKUPVOLUME utility to read your backup volumes and display the information needed to arrange them in order (backup series, backup operation, and volume sequence):
A sample JCL:
//TIVSM JOB MSGLEVEL=(1,1), // REGION=40M,TIME=1440,CLASS=A,MSGCLASS=H //*------------------------------------------------------------- //SERVER EXEC PGM=DSMSERV,DYNAMNBR=300 // PARM='/DISPLAY DBB DEV=TAPECLASS VOL=FILE:DD:THEVOLS' //OPT DD DSN=SERVER.OPTIONS,DISP=MOD //DSMAMENG DD DSN=TIVSM.SANRMSG(ANRMENU),DISP=SHR //HLPAMENG DD DSN=TIVSM.SANRHLP(ANRHENU),DISP=SHR //IDL DD DSN=TIVSM.SANRIMG(ANRIDL),DISP=SHR //DSK DD DSN=TIVSM.DISKLOG,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSTERM DD SYSOUT=* //THEVOLS DD * 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:A sample JCL:
//TIVSM JOB MSGLEVEL=(1,1), // REGION=40M,TIME=1440,CLASS=A,MSGCLASS=H //* //*------------------------------------------------------------------ //* //RESTOR1 EXEC PGM=DSMSERV,DYNAMNBR=300 // PARM='/RESTORE DB DEV=TAPECLASS VOL=FILE:DD:THEVOLS COMMIT=NO' //OPT DD DSN=SERVER.OPTIONS,DISP=MOD //DSMAMENG DD DSN=TIVSM.SANRMSG(ANRMENU),DISP=SHR //HLPAMENG DD DSN=TIVSM.SANRHLP(ANRHENU),DISP=SHR //IDL DD DSN=TIVSM.SANRIMG(ANRIDL),DISP=SHR //DSK DD DSN=TIVSM.DISKLOG,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSTERM DD SYSOUT=* //THEVOLS DD * DSM023 DSM037 DSM087 //* //*------------------------------------------------------------------ //* //RESTOR2 EXEC PGM=DSMSERV,DYNAMNBR=300 // PARM='/RESTORE DB DEV=TAPECLASS VOL=DSM012 COMMIT=NO' //OPT DD DSN=SERVER.OPTIONS,DISP=MOD //DSMAMENG DD DSN=TIVSM.SANRMSG(ANRMENU),DISP=SHR //HLPAMENG DD DSN=TIVSM.SANRHLP(ANRHENU),DISP=SHR //IDL DD DSN=TIVSM.SANRIMG(ANRIDL),DISP=SHR //DSK DD DSN=TIVSM.DISKLOG,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSTERM DD SYSOUT=* //* //*------------------------------------------------------------------ //* //RESTOR3 EXEC PGM=DSMSERV,DYNAMNBR=300 // PARM='/RESTORE DB DEV=TAPECLASS VOL=DSM038,DSM058 COMMIT=NO' //OPT DD DSN=SERVER.OPTIONS,DISP=MOD //DSMAMENG DD DSN=TIVSM.SANRMSG(ANRMENU),DISP=SHR //HLPAMENG DD DSN=TIVSM.SANRHLP(ANRHENU),DISP=SHR //IDL DD DSN=TIVSM.SANRIMG(ANRIDL),DISP=SHR //DSK DD DSN=TIVSM.DISKLOG,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSTERM DD SYSOUT=* //* //
Attention: If the original database or recovery log volumes are available, you issue only the DSMSERV RESTORE DB utility. 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 utility.
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 roll-forward 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 roll-forward recovery to restore a database to its most current state if:
You can only use full and incremental backups with roll-forward mode enabled to restore a database to its most current state. Snapshot database backups are complete database copies of a point-in-time.
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 utility. 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 utility.
Note: | Roll-forward recovery does not apply if all recovery log volumes are lost. However, with the server running in roll-forward mode, you can still perform point-in-time recovery in such a case. |
You can recreate files in a primary storage pool by using
duplicate copies in copy storage pools. 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, TSM determines which files are in the storage pool being restored, according to the TSM database. Using file copies from a copy storage pool, TSM 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 TSM 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.