In this example, a library manager's corrupted database
is restored. You can modify the procedure to meet your needs.
About this task
In a Tivoli® Storage
Manager shared
library environment, the server that manages and controls the shared
library is known as the library manager. The library manager maintains
a database of the volumes within the shared library.
Procedure
Complete the following steps to restore the corrupted
database:
- Copy the volume history file to a temporary location and
rename the file. After the database is restored, any volume
history information that is pointed to by the server options is lost.
You need this information to identify the volumes to be audited.
- Put the device configuration file and the server options
file in the server working directory. You can no longer recreate the
device configuration file; you must have a copy of the original.
- Gather the outputs from your detailed queries about your
database and recovery log setup information.
- Determine whether the original database and recovery log
directories exist. If the original database or recovery
log directories were lost, recreate them using the operating system mkdir command.
Note: The
directories must have the same name as the original directories.
- Use the DSMSERV RESTORE DB utility to
restore the database to the current time.
- Start the Tivoli Storage
Manager server instance.
- Issue an AUDIT LIBRARY command from
each library client for each shared library.
- Create a list from the old volume history information (generated
by the QUERY VOLHISTORY command) that shows all
of 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.
- Audit all disk volumes, all reused volumes, and any deleted
volumes located by the AUDIT VOLUME command using
the FIX=YES parameter.
- Issue the RESTORE STGPOOL command to
restore those files detected as damaged by the audit. Include the FIX=YES parameter
on the AUDIT VOLUME command to delete database
entries for files not found in the copy storage pool or active-data
pool.
- Mark any volumes that cannot be located as destroyed, and
recover those volumes from copy storage pool backups. Recovery from
active-data pool volumes is not suggested unless the loss of inactive
data is acceptable. 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.
Results
Note: When a database is loaded or restored, the server-to-server
communication verification token is changed. The verification token
is an attribute of the database and is not stored in the database
itself. Part of the token is the installation date and time for the
database. For servers that are defined for server-to-server communications,
issue an UPDATE SERVER command with FORCESYNC=YES.