Tivoli Header

Administrator's Guide


Recovering Your Server Using Database and Storage Pool Backups

This section explains how to recover by using backups of the database and storage pools. Figure 81 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 81. Recovery from a Disaster

Recovery from a Disaster

The following topics are included:

To perform a restore, you should have the following information, preferably stored offsite (see Figure 81):

Note:
To perform a DSMSERV RESTORE DB operation, the database backup volumes must be in a library of a library type of MANUAL or SCSI.


DRM Icon

DRM can query the server and generate a current, detailed disaster recovery plan for your installation.

Restoring a Database to a Point-in-Time

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.

For a scenario of recovering to a point-in-time, see Backup and Recovery Scenarios.

Here is the procedure for restoring the database:

  1. Rename and save a copy of the volume history file if it exists. After the database is restored, any volume history information pointed to by the server options is lost. You will need this information to identify the volumes to be audited. If you do not have a volume history file, see Point-in-Time Restore Without a Volume History File.
  2. If the device configuration file is unavailable, recreate it manually (see Recreating a Device Configuration File). Put the existing or recreated device configuration file in the server work library. Do the same with the server options file. Have available your outputs from your detailed queries about your database and recovery log setup information.

    You may need to modify the device configuration file based on the hardware available at the recovery site. For example, the recovery site might require a different device class, library, and drive definitions. For more information, see Updating the Device Configuration File.

  3. If the original database or recovery log volumes were lost, issue the DSMSERV FORMAT utility to initialize the database and recovery log. For example:
     dsmserv format 1 log1 9 1 dbvol1 5
    

    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.

  4. Issue the DSMSERV RESTORE DB utility. For example, to restore the database to a backup series that was created on April 19, 1999, enter:
     dsmserv restore db todate=04/19/1999
    

    The server does the following:

    1. Reads the volume history file to locate the last full backup that occurred on or before the specified date and time.
      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.
    2. Using the device configuration file, requests a mount of the first volume, which should contain the beginning of the full backup.
    3. Restores the backup data from the first volume.
    4. Continues to request mounts and to restore data from the backup volumes that contain the full backup and any incremental backups that occurred on or before the date specified.

    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.

  5. Audit all disk volumes, all reused volumes, and any deleted volumes located by the AUDIT VOLUME command using the FIX=YES parameter.

    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.

  6. If the audit detects any damaged files, issue the RESTORE STGPOOL command to restore those files after you have audited the volumes in the storage pool. Include the FIX=YES parameter on the AUDIT VOLUME command to delete database entries for files not found in the copy storage pool.
  7. Mark as destroyed any volumes that cannot be located, and recover those volumes from copy storage pool backups. If no backups are available, delete the volumes from the database by using the DELETE VOLUME command with the DISCARDDATA=YES parameter.
  8. Redefine any storage pool volumes that were added since the database backup.

Notes:

  1. 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. See Delaying Reuse of Sequential Access Volumes for more information on the REUSEDELAY parameter.

  2. By backing up your storage pool and your database, you reduce the risk of losing data. To further minimize loss of data, you can:

  3. 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.

  4. After a restore, the volume inventories for Tivoli Storage Manager and for your tape management system may be inconsistent. For example, after a database backup, a new volume is added to Tivoli Storage Manager. The tape management system inventory records the volume as belonging to Tivoli Storage Manager. If the database is restored from the backup, Tivoli Storage Manager has no record of the added volume, but the tape management system does. You must synchronize these inventories. Similarly, the volume inventories for Tivoli Storage Manager and for any automated libraries may also be inconsistent. If they are, issue the AUDIT LIBRARY command to synchronize these inventories.

Point-in-Time Restore Without a Volume History File

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). For example:

 dsmserv display dbbackupvolume devclass=tapeclass
  volumenames=dsm012,dsm023,dsm037,dsm038,dsm058,dsm087

For example, the most recent backup series consists of three operations:

0
A full backup on three volumes in the sequence dsm023, dsm037, and dsm087

1
An incremental backup on one volume, dsm012

2
An incremental backup on two volumes in the sequence dsm038 and dsm058

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 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.

Storage Pool Backups in a Point-of-Time Restore

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.

9:30 a.m.
Client A backs up its data to Volume 1.

Noon
The system administrator backs up the database.

1:30 p.m.
Client A's files on Volume 1 (disk), is migrated to tape (Volume 2).

3:00 p.m.
Client B backs up its data to Volume 1.

The server places Client B's files in the location that contained Client A's files prior to the migration.

3:30 p.m.
The server goes down.

3:40 p.m.
The system administrator reloads the noon version of the database by using the DSMSERV RESTORE DB utility.

4:40 p.m.
Volume 1 is audited. The following then occurs:
  1. The server compares the information on Volume 1 and with the restored database (which matches the database at noon).
  2. The audit does not find Client A's files on Volume 1 where the reloaded database indicates they should be. Therefore, the server deletes these Client A file references.
  3. The database has no record that Client A's files are on Volume 2, and the files are, in effect, lost.
  4. The database has no record that Client B's files are on Volume 1, and the files are, in effect, lost.

If roll-forward recovery had been used, the database would have been rolled forward to 3:30 p.m. when the server went down. In this case, 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. Those files could have been restored with a RESTORE VOLUME or RESTORE STGPOOL command. Client B's files would still have been lost, however.

Restoring a Database to its Most Current State

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 utility 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.

Restoring Storage Pools

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:

Primary storage pool
Specifies the name of the primary storage pool that is being restored.

Copy storage pool
Specifies the name of the copy storage pool from which the files are to be restored. This information is optional. If you do not specify a copy storage pool, the server restores the files from any copy storage pool where it can find them.

New storage pool
Specifies the name of the new primary storage pool to which to restore the files. This information is optional. If you do not specify a new storage pool, the server restores the files to the original primary storage pool.

Maximum number of processes
Specifies the maximum number of parallel processes that are used for restoring files.

Preview
Specifies whether you want to preview the restore operation without actually restoring data.

See Correcting Damaged Files and Backup and Recovery Scenarios for examples of using the RESTORE STGPOOL command.

What Happens When a Storage Pool Is Restored

When you restore a storage pool, Tivoli Storage Manager determines which files are in that storage pool. Using file copies from a copy storage pool, Tivoli Storage Manager 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 Tivoli Storage Manager 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.

Restoring Files to a Storage Pool with Collocation Enabled

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:

  1. Restoring the files first to a random access storage pool (on disk).
  2. Allowing or forcing the files to migrate to the target primary storage pool.

    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.

When a Storage Pool Restoration Is Incomplete

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:


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