Disasters, by their very nature, cannot be predicted, in either their intensity, timing, or effects. However, all enterprises can and should prepare for whatever might happen in order to protect themselves against loss of data or, worse, their entire business. It is too late to start preparing after a disaster occurs. This article will help you as a TSM Administrator to protect against a disaster - taking you step by step through the planning and recovering stages.
TSM Disaster Recovery Concepts, Constructs and Methodologies:
Before an administrator can start implementing disaster recovery plans for TSM managed data, there are several concepts and constructs that must be understood.
The TSM Database
The TSM database is the heart of a TSM server; without the database, the server is dead! There is no way to restore TSM backups (except for client backup sets) without the database. Most administrators choose to keep 4-5 daily backups of the TSM database. If an administrator is doing off-site disaster recovery planning, he or she usually chooses to keep two sets of 4-5 daily backups of the TSM database; one set is kept on-site for immediate recovery while another is kept at an off-site location in case of total facility loss.
Device Configuration and Volume History
TSM stores information about volumes (e.g. tapes) it uses in its database. Specifically, when a database backup is made, a record is created in the TSM database containing the volume serial number of the tape used for the backup, the date, and the type of backup (e.g. full, snapshot, etc). Since there may be hundreds of tapes in a library, this information is needed in order to find the most recent backup.
A volume history file to be created file contains information on all the volumes used by the TSM server, including the volumes used for database backup. The file is typically created on a daily basis after the database backup is made, and when restoring the database, the file can be used to find the tape that contains the appropriate database backup to restore.
Just like the volume history, TSM stores information on connected storage devices in its database. And just like volume information, an administrator will need to use those devices to restore the database in the event of its loss. The TSM server, thus, allows device information to be written to a text file called a device configuration file. This file is usually created daily and is read by the server when restoring the database from backup.
Copy Storage Pools
TSM backed up and archived data is stored on storage pools which are, by definition, collections of like media. TSM allows a storage pool to be duplicated to protect against loss or failure of media. This storage pool backup is called a copy storage pool. It is recommended to have at least one copy storage pool for all data that is stored on tape. The copy storage pool can be stored at a physical location which is separate from the primary storage pool (i.e. outside the tape library or off-site) for disaster recovery purposes.
A) Prepare and backup data & files needed for recovery (before disaster)
These should be included in TSM daily schedule administrative tasks for a server.
To keep the Tivoli Storage Manager database safe is to create regular Full backups and periodic Incremental backups. This type of process can be scheduled inside of TSM so that it occurs at regularly scheduled intervals.
Step 1: Defining device classes for database backups
Step 2: Doing Full and Incremental Backup
** The first backup of your database must be a full backup. You can run up to 32 incremental backups between full backups.
Backup dsmserv.opt file
Save a copy of dsmserv.opt to your backup directory
Backup Device Configuration (Devconfig) and Volume History (Volhist
For Item I) and III), you can create a backup script. Suggested to gather these items into a single scheduled set of commands. The reason is that some of the steps need to occur in the correct sequence and this makes sure that they do. The steps as below:
Step 1 : Define the script
Step 2 : Test run the script
Step 3 : Define a schedule to run the script daily
B) Recovering the server (after disaster)
This section provides an overview of the tasks involved in recovering the server. The steps are performed by the on-site administrator. Here are the very brief guidelines for recovering your server:
Locate a suitable replacement machine.
Restore the operating system, the Tivoli Storage Manager server software, the Tivoli Storage Manager licenses, and the administrative client on the replacement hardware. Ensure that the environment is in the original. The environment includes:
The directory structure and location of the TSM server executable, enrollment certificates, administrative command line client, and disk formatting utility.
The directory structure for TSM server instance-specific files and the database, log, and storage pool volumes
Copy the TSM server options file (dsmserv.opt) that you backup previously to its original location.
Copy the volume history file (volhist.out) and device configuration file (devconfig.out)required by database restore to its original location.
Issue the DSMSERV RESTORE DB command.
Start the server.
Register TSM server licenses.
Due to changes in hardware configuration during recovery, you might have to update the device configuration file in the restored Tivoli Storage Manager database. You can get the details on this guidelines from IBM Knowledge Center at :
“Recovering from a disaster” via this link :