Tivoli Storage Manager for Windows Administrator's Guide


Setting Up and Using Tivoli Disaster Recovery Manager

Here is an overview of the DRM set up tasks. Additional details are available in later sections, and you can find a checklist at Tivoli Disaster Recovery Manager Checklist.

Set Up for Server Recovery:

  1. Register the DRM license.
  2. Define information about the server machine.
  3. Back up the primary storage pools.
  4. Back up the database.
  5. Track the movement of the backup volumes.
  6. Create the disaster recovery plan.

Set Up for Storage of Client Recovery Information:

  1. Prioritize Tivoli Storage Manager clients based on application or business needs.
  2. Schedule automatic client data backups.
  3. Define your disaster recovery information for the client machines.
  4. Define the boot media requirements for the client machines.
  5. Associate machines with recovery media.

Licensing Tivoli Disaster Recovery Manager

To use DRM, register the DRM license by entering the following:

register license file=drm.lic

For more information, see Registering Licensed Features.

Defining Tivoli Storage Manager Server Machine Information

During disaster recovery, you need server machine information to rebuild the replacement machine. To store this information, issue the DEFINE MACHINE command (see Defining Client Node Machine Information) and set the ADSMSERVER parameter to YES.

You can include additional information about hardware, software, and boot media by following the steps in Defining Client Node Machine Information and Defining and Tracking Recovery Media.

Backing up the Primary Storage Pools and the Database

Before creating a disaster recovery plan, back up your storage pools then the database.

Note:Always back up your storage pools before backing up the database.
For example:
  1. Back up the storage pool BACKUPPOOL to the copy storage pool CSTORAGEPF:
    backup stgpool backuppool cstoragepf
    
  2. Perform a full database back up using the device class LIB8MM, and store the backup on volume BK06:
    backup db devclass=lib8mm type=full volumename=bk06
    
    Note:You can also perform database snapshot backups, which are full backups but which do not interrupt the current full plus incremental backup series. In this way, you can retain your full plus incremental backup series on site to recover from possible availability problems.

If you manually send backup media offsite, see Sending Server Backup Volumes Offsite. If you use virtual volumes, see Using Virtual Volumes to Store Data on Another Server.

When your backups are both offsite and marked offsite, you can create a disaster recovery plan.

Creating and Storing the Disaster Recovery Plan


Task Required Privilege Class
Create a recovery plan file System

Use the PREPARE command to create a disaster recovery plan file. For details about the recovery plan file, see The Disaster Recovery Plan. You can store the file locally or on another server as an object on a target server.

DRM creates one copy of the disaster recovery plan file each time you issue the PREPARE command. You should create multiple copies of the plan for safekeeping. For example, keep copies in print, on diskettes, on network mounted disk space that is located offsite, or on a remote server.

To keep the plan current, run the PREPARE command after you back up storage pools and the database and mark the copy storage pool volumes offsite. You can also use the Tivoli Storage Manager scheduler to periodically run the PREPARE command (see Chapter 17, Automating Server Operations).

Note:DRM creates a plan that assumes that the latest database full plus incremental series would be used to restore the database. However, you may want to use DBSNAPSHOT backups for disaster recovery and retain your full plus incremental backup series on site to recover from possible availability problems. In this case, you must specify the use of DBSNAPSHOT backups in the PREPARE command. For example:
prepare source=dbsnapshot

Storing the Disaster Recovery Plan Locally

If you issue the PREPARE command without the DEVCLASS parameter, you store the recovery plan file locally in a file system. If you store the file locally, you can specify a storage location (see Prefix for the Recovery Plan File). Recovery plan files that are stored locally are not automatically expired. You can expire recovery plan files that are stored on a target server by using the DRMRPFEXPIREDAYS command. You should periodically delete down-level recovery plan files.

For example, to store the recovery plan file locally in the c:\win32app\ibm\adsm\server2\recplans\ directory, enter:

prepare planprefix=c:\win32app\ibm\adsm\server2\recplans\

TSM appends to the file name the date and time (yyyymmdd.hhmmss). For example:

c:\win32app\ibm\adsm\server2\recplans\19990925.120532

Storing the Disaster Recovery Plan on a Target Server

If you issue the PREPARE command with the DEVCLASS parameter, you store the recovery plan file on a target server. Some benefits of storing recovery plan files on a target server are:

Before issuing the PREPARE command, you must set up the source and target servers and define a device class (see Setting Up Source and Target Servers for Virtual Volumes for details). The device class definition must specify a device type of SERVER. The DEVCLASS parameter on the PREPARE command specifies the device class name that is used to create a recovery plan file object. The recovery plan file is written as an object on the target server, and a volume history record is created on the source server. For example, assume a device class named TARGETCLASS is defined on the source server where the PREPARE command is to be issued. To store a recovery plan file from the source server onto the target server, enter:

prepare devclass=targetclass

For more about recovery plan files that are stored on target servers, see Querying, Displaying, and Expiring Recovery Plan Files Saved on a Target Server.

Disaster Recovery Plan Environmental Considerations

If TSM is installed in the c:\win32app\ibm\adsm directory, the files are stored as follows:

Each instance of the server has a unique set of files. For example, after you install the database and log volumes from directory c:\win32app\ibm\adsm\server2, you might see the following in this instance-specific directory:

The database, log, and storage pool volumes could also be in a different directory. For example, you might see:

c:\win32app\ibm\adsm\server2\dbs\db1.dsm
c:\win32app\ibm\adsm\server2\logs\log1.dsm
c:\win32app\ibm\adsm\server2\stg\data1.dsm

Files that typically reside in an instance-pecific directory (that is, dsmserv.opt, dsmserv.dsk) and database, log, and storage pool volumes may instead reside in the same directory in which dsmserv.exe, resides (c:\win32app\ibm\adsm\server). In this case, the directory containing dsmserv.exe would also be referred to as the instance-specific directory.

When the disaster recovery plan is created, information about the server environment is used in the stanzas within the plan file. This environmental information includes the location of dsmserv.exe, the location of the disk formatting utility, the instance-specific directory, the directories for the database, log, and storage pool volumes, and so on. During a recovery, it is assumed that the same server environment exists.

Additionally, the plan file itself will reside in a directory that you may have specified or it may reside in the default directory (which is the instance-specific directory). For example, if you specified the disaster recovery plan file prefix c:\win32app\ibm\adsm\server2\prepare\, you might see the following:

c:\win32app\ibm\adsm\server2\prepare\19950925.120532

The disaster recovery plan file prefix specified (or the instance-specific directory if no disaster recovery plan file prefix was specified) is also used in the stanzas within the plan file. During a recovery, when the plan file has been split into individual files, it is assumed that these individual files will reside in this same directory.

To summarize, the environment for a recovery using the disaster recovery plan file is assumed to be the same as the original environment which includes:

If the recovery environment is not the same, then you must edit the plan file to account for the changes in the environment.

To help understand where these various directories and expected locations for executables are used within the plan file, see Example Disaster Recovery Plan File and you will see the following usage:

Usage Directory
Server executable c:\win32app\ibm\adsm\server
Enrollment certificates (licensing) c:\win32app\ibm\adsm\server
Administrative command line client c:\win32app\ibm\adsm\saclient
Disk formatting utility c:\win32app\ibm\adsm\utils
Instance-specific files c:\win32app\ibm\adsm\server2
Database volumes c:\win32app\ibm\adsm\server2\dbs
Log volumes c:\win32app\ibm\adsm\server2\logs
Storage pool volumes c:\win32app\ibm\adsm\server2\stg
Plan file location c:\win32app\ibm\adsm\server2\prepare
Indivual files split out from plan c:\win32app\ibm\adsm\server2\prepare

Querying, Displaying, and Expiring Recovery Plan Files Saved on a Target Server

Querying Information about Recovery Plan Files


Task Required Privilege Class
Display a list of disaster recovery plan files Any Administrator

Use the QUERY RPFILE command to display a list of recovery plan files. You can issue the command from the server that created the files (the source server) or from the server on which the files are stored (the target server):

The list of recovery plan files is limited to those that were created assuming either full plus incremental database backup series (the default) or database snapshot backups. For example, from the source server to list only files created assuming database snapshot backups, enter:

query rpfile devclass=* source=dbsnapshot

From the source server, you can also issue the QUERY VOLHISTORY command to display a list of all recovery plan files for the source server by entering:

query volhistory type=rpfile
The preceding command limits the query to records that contain information about recovery plan files that were created assuming full and incremental database backup series. To limit the deletion to records that contain information about recovery plan files created assuming database snapshot backups, specify TYPE=RPFSNAPSHOT.

Displaying the Contents of a Recovery Plan File


Task Required Privilege Class
Display the contents of a disaster recovery plan file System

Use the QUERY RPFCONTENT command to display the contents of a recovery plan file that was saved as on object on the target server. You can issue the command either from the server that created the files (the source server) or from the server on which the files are stored (the target server):

See The Disaster Recovery Plan for an example of the contents of a recovery plan file.

Note:An output delay can occur when the plan file is located on tape.

Restoring a Recovery Plan File


Task Required Privilege Class
Restore a disaster recovery plan file System

To restore a recovery plan file and direct the output to a file, use the QUERY RPFCONTENT command. You can issue the command from the server that created the files (the source server) or from the server on which the files are stored (the target server). If you are uncertain about the name of the recovery plan file, you can display a list of files by issuing the QUERY RPFILE command.

Assume that you want to restore the recovery plan file named marketing.19990831.045000. The recovery plan file was created using the device class of TARGETCLASS and on a source server whose node name at the target server is BRANCH8. You want to restore the recovery plan file to a file named rpf.out:

To display a list of recovery plan files, use the QUERY RPFILE command. For example, to list the recovery plan files for the source server with a node name of BRANCH8 and that was created assuming full plus incremental database backup series, issue the following command:

query rpfile nodename=branch8 

Setting Up Automatic Expiration of Recovery Plan Files


Task Required Privilege Class
Set the time for recovery plan file expiration System

You can set DRM to expire recovery plan files a certain number of days after they are created. To set up expiration, issue the SET DRMRPFEXPIREDAYS command. The default value is 60 days. For example, to change the time to 90 days, enter:

set drmrpfexpiredays 90

All recovery plan files that meet the criteria are eligible for expiration if both of the following conditions exist:

Manually Deleting Recovery Plan Files


Task Required Privilege Class
Delete recovery plan file objects from a target server System

You can use the DELETE VOLHISTORY command to delete records containing information about recovery plan file objects. For example, to delete recovery plan files that were created on or before 08/30/1999 and assuming full plus incremental database backup series, enter:

delete volhistory type=rpfile todate=08/30/1999
To limit the query to records that contain information about recovery plan files and that were created assuming database snapshot backups, specify TYPE=RPFSNAPSHOT.

The record for the latest recovery plan file is not deleted. When the records are deleted from the source server and the grace period is reached, the objects are deleted from the target server.

Storing Client Recovery Information

DRM lets you store recovery information for client machines backed up by the server.

Task Required Privilege Class

Define machine information
Associate client nodes with machines
Define and tracking machine recovery media
Associate recovery media with machines

System

Defining Client Node Machine Information

Client node machine information can help you identify what you need to rebuild or restore the replacement machines.

Note:You do not have to define machine characteristics and recovery instructions during the set up process. You can do this later.
You can specify the following information:
  1. To specify the client location and business priority, issue the DEFINE MACHINE command. For example, to define machine MACH22 in building 021, 2nd floor, in room 2929, with a priority of 1, enter:
    define machine mach22 building=021 floor=2 room=2929 priority=1
    
  2. To associate one or more client nodes with a machine, issue the DEFINE MACHNODEASSOCIATION command.

    During disaster recovery, this association information is used to determine which client nodes were on machines that were destroyed. The file spaces associated with these client nodes should be restored. For example, to associate node CAMPBELL with machine MACH22, enter:

    define machnodeassociation mach22 campbell
    

    To query machine definitions, issue the QUERY MACHINE command. See the example, in Recovering Clients Scenario.

  3. To add machine characteristics and recovery instructions to the database, issue the INSERT MACHINE command. You must first query the operating system to identify the characteristics for your client machine. You can add the information manually or use a Microsoft VBScript command procedure (see Figure 86 for an example).

Defining and Tracking Recovery Media

Follow these steps to save a description of the bootable media required to reinitialize or reinstall an operating system on a client machine, and associate one or more machines with this media. You can also use these commands to associate non-executable media such as application user guides with client machines.

  1. To define the bootable media needed to recover one or more machines, issue the DEFINE RECOVERYMEDIA command. In the following example, the boot recovery media name is tellerwrkstnimage, the volume list includes aix001, aix002, and aix003, for product AIX 4.1. The location of the recovery media is Building 21.
    define recoverymedia tellerwrkstnimage volumenames=aix001,aix002,aix003
      type=boot product="AIX 4.1" location="Building 21"
    

    This command is usually needed only when a client machine configuration changes. For example, assume that you have installed a new level of AIX on the client machine and created a bootable image using mksysb. To define the new mksysb volumes, issue another DEFINE RECOVERYMEDIA command.

    To query your recovery media definitions, issue the QUERY RECOVERYMEDIA command with the FORMAT=DETAILED parameter.

  2. To associate one or more machines with recovery media, use the DEFINE RECMEDMACHASSOCIATION command. First, however, both the machine and recovery media must be defined. This association information can be used to determine what boot media to use in the replacement machines.

    The following example associates machine MACH255 with recovery media tellerwrkstnimage:

    define recmedmachassociation tellerwrkstnimage mach255
    
  3. When the boot media is moved offsite, update the location with the UPDATE RECOVERYMEDIA command.

    The following example updates the location of boot media tellerwrkstnimage to the offsite location IRONVAULT:

    update recoverymedia tellerwrkstnimage location=ironvault
    

In a recovery scenario, you may want to have softcopy manuals that are on a CD-ROM. You can define this to DRM with the DEFINE RECOVERYMEDIA command. For example, to define the AIX 4.1 manuals (TYPE=OTHER) that are on volume cd0001, enter:

define recoverymedia aix41manuals description="AIX 4.1 Bookshelf" -
  volumes=cd0001 type=other


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