The Tivoli Storage Manager database and Recovery Logs contains all of the information that is required to perform backup and restore functions. The Tivoli Storage Manager database is the heart of Tivoli Storage Manager. You need to take backup of this database in regular intervals in order to restore the database to the current state if any disaster occurs.
How to restore or recover Tivoli Storage Manager Database
To restore only the Tivoli Storage Manager database, the following files must be available
- Database backup, last full and incremental or snapshot Recovery log
- Volume history file (volhist.out)
- Device configuration file (devconfig.out)
- dsmserv.opt
Also Read: TSM server important configuration files
If you want to restore the whole TSM server and primary storage pools, the following backups and files must be available
If you want to restore the whole TSM server and primary storage pools, the following backups and files must be available
- Database backup, last full and incremental or snapshot
- Storage pool backups (copypools)
- Volume history file (volhist.out)
- Server options file (dsmserv.opt)
- Device configuration file (devconfig.out)
If you have the above mention files, you can restore the database to one of two states by using dsmserv restore db command
- To its most current state
- To a point in time
The DSMSERV RESTORE DB command provides the following functions:
- Restoring the database to its most current state so that a site can protect against loss of client and server files because of a hardware failure on the Tivoli Storage Manager server.
- The dsmserv restore db utility uses backed up versions of the database that you create manually by using the backup db command or versions that are created by the automatically triggered database backups.
Restoring a database to the most current state
dsmserv restore db
If the original database or recovery log volumes are available, you issue only the DSMSERV RESTORE DB command. However, if those volumes are lost, you must first issue the DSMSERV FORMAT command to initialize the database and recovery log, and then issue the DSMSERV RESTORE DB command.
Restoring a database to a point-in-time
Use point-in-time recovery for situations such as disaster recovery or removing the effects of errors that might cause inconsistencies in the database. To restore the database, the following files must be available
- Database backup, full plus incremental or snapshot
- Volume history file
- Device configuration file
- Recovery log (archive log)
- Server options (dsmserv.opt)
Also Read: How to protect TIvoli Storage Manager Database
If a backup copy of volume history information is available, you can restore a database to a specific point in time. TODate = date specifies the date to restore the database to. This parameter is required.
If a backup copy of volume history information is available, you can restore a database to a specific point in time. TODate = date specifies the date to restore the database to. This parameter is required.
dsmserv restore db todate=07/12/2014 totime=18:45
If the volume history file is unavailable, you can use one or more dsmserv restore db utilities to restore a Tivoli Storage Manager database to a specific point in time. For example, if you need to load a regular backup and one or more incremental backups, you can issue a dsmserv restore db command to restore the regular backup. Afterward, you issue an additional dsmserv restore db command for each incremental backup. When you use multiple dsmserv restore db utilities, you must specify COMMIT = NO for each command except the last one that you issue. For the last dsmserv restore db command, you must specify COMMIT = YES to place the database in a consistent and usable state.
Things to consider when restoring TSM database using point-in-time recovery
- After the database is restored, volume history information that the server options pointed to is lost. Because of this, be sure to rename and save a copy of the volume history file if it exists. You will need this information to identify the volumes to audit.
- If the device configuration file is unavailable, recreate it manually. Put the existing or recreated device configuration file in the server work library. Do the same for the server options file. You might need to edit the device configuration file if the hardware is different at the recovery site.
- The DSMSERV FORMAT utility initializes the database and recovery log.
- Starting the server before the restore operation destroys existing volume history files. Do not start the server until after you restore the database.
Tips for restoring TSM Database
- To restore the database to the most recent state, the roll-forward mode must be set. Using this mode, you can restore the database up to the last finished transaction.
- Schedule a database backup immediately after the storage pool backup finishes. If you use the storage pool copy to make a backup of the primary storage pool, schedule the database backup to run when the storage copy pool finishes. If you do that, you have a database backup that reflects the storage pool backup. If a disaster recovery situation occurs, you can use the database backup and the storage copy pool backups to restore the Tivoli Storage Manager environment. These backups restore the environment to the time that the backups are sent to an off-site location.
- Store a copy of the DSMSERV.OPT file off-site to protect it from disaster recovery at the installation site.
- Define volume history and device class backup files. The volume history and device class backup files are used during database restore. If the volume history information is not available when you do a point-in-time restore operation, you do not know which storage pool to audit. Consequently, you need to audit all storage pools. If the device configuration is not available, you must define all device classes, drives, and libraries manually.
- In a copy storage pool definition, the REUSEDELAY parameter delays volumes from being returned to scratch or being reused. Set the value high enough to ensure that you can restore the database to an earlier point in time and that database references to files in the storage pool are valid. For example, to retain database backups for seven days, set REUSEDELAY to 7.
- Consider using the disaster recovery manager function for managing copy storage pool volumes.
- Use recovery log mirroring if you have enough space. The recovery log is vital to restore to the most recent state. If you use mirroring for the recovery log, you are protected against media failure, and you can always restore to the most recent state even if a media failure affects one of the recovery logs.
How to increase the TSM Activelog size
Increasing the active log size. Under normal conditions, you do not need to increase the size of the active log. However, if the log starts running out of space, the current transaction is rolled back, and the server issues an error message and halts. You cannot restart the server until the active log size is increased. To increase the size of the active log, perform the following steps
- Issue the DSMSERV DISPLAY LOG offline utility to verify the size of the active log.
- In the dsmserv.opt file, update ACTIVELOGSIZE server option to the new maximum size of the active log, in megabytes. For example, to change the active log to its maximum size of 128 GB, enter the server option
activelogsize 204800
- If you want to use a new active log directory, update the directory name that the ACTIVELOGDIR server option specifies. The new directory must already exist, be empty, and be accessible to the database manager.
- Restart the server.
Mirrored copies of the active log consume additional disk space because of the larger recovery log size. Mirror both your active log and the archive log if you have enough disk space.
0 Comment to "10.7 How to restore TSM Server Database and recoverylogs"
Post a Comment