Tivoli Storage Manager for Windows: Administrator's Guide
This section explains how to recover by using backups of the database and
storage pools. Figure 88 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 88. Recovery from a Disaster

The following topics are included:
- Restoring to a point-in-time
- Restoring to the most current state
To perform a restore, you should have the following information, preferably
stored offsite (see Figure 88):
- A full database backup
- Any incremental database backups between the last full backup and the
point-in-time to which you are recovering
- Copy storage pool volumes
- On tape or diskette, or as printouts:
- Server options file
- Volume history file
- Device configuration file with the applicable device information (library,
drive, and device class definitions)
- Database and recovery log setup (the output from detailed queries of your
database and recovery log volumes)

| DRM can query the 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.
For a scenario of recovering to a point-in-time, see Backup and Recovery Scenarios.
Here is the procedure for restoring the database:
- 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.
- 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.
- 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.
- 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:
- 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.
- Using the device configuration file, requests a mount of the first volume,
which should contain the beginning of the full backup.
- Restores the backup data from the first volume.
- 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.
- 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.
- 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.
- 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.
- Redefine any storage pool volumes that were added since the database
backup.
Notes:
- 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.
- By backing up your storage pool and your database, you reduce the risk of
losing data. To further minimize loss of data, you can:
- Mark the backup volumes in the copy storage pool as OFFSITE and move them
to an offsite location.
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.
To avoid having to mark volumes as offsite or physically move
volumes:
- Specify a device class of DEVTYPE=SERVER in your database backup.
- Back up a primary storage pool to a copy storage pool associated with a
device class of DEVTYPE=SERVER.
- Back up the database immediately after you back up the storage
pools.
- Turn off migration and reclamation while you back up the database.
- Do not perform any MOVE DATA operations while you back up the
database.
- Use the REUSEDELAY parameter's interval to prevent your copy storage
pool volumes from being reused or deleted before they might be needed.
- 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 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.
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.
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:
- The server compares the information on Volume 1 and with the restored
database (which matches the database at noon).
- 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.
- The database has no record that Client A's files are on Volume 2, and
the files are, in effect, lost.
- 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.
You can use roll-forward recovery to restore a database to its most current
state if:
- The server has been in roll-forward mode continuously from the time of the
last full backup to the time the database was damaged or lost.
- The last backup series created for the database is available. A
backup series consists of a full backup, all applicable incremental backups,
and all recovery log records for database changes since the last backup in the
series was run.
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.
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:
- The primary copy of the file has been identified as having read errors
during a previous operation. Files with read errors are marked as
damaged.
- The primary copy of the file resides on a volume that has an access mode
of DESTROYED. For how the access mode of a volume changes to the
DESTROYED access mode, see How Restore Processing Works.
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.
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.
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:
- Restoring the files first to a random access storage pool (on
disk).
- 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.
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:
- Either files were never backed up, or the backup copies were marked as
damaged.
- A copy storage pool was specified on the RESTORE command, but files were
backed up to a different copy storage pool. If you suspect this is a
problem, use the RESTORE command again without specifying a copy storage pool
from which to restore files. The PREVIEW option can be used on the
second RESTORE command, if you do not actually want to restore files.
- Volumes in the copy storage pool needed to perform the restore operation
are offsite or unavailable. Check the activity log for messages that
occurred during restore processing.
- Backup file copies in copy storage pools were moved or deleted by other
processes during restore processing. To prevent this problem, do not
issue the following commands for copy storage pool volumes while restore
processing is in progress:
- MOVE DATA
- DELETE VOLUME (DISCARDDATA=YES)
- AUDIT VOLUME (FIX=YES)
- You can prevent reclamation processing for your copy storage pools by
setting the RECLAIM parameter to 100 with the UPDATE STGPOOL command.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]