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:
Set Up for Storage of Client Recovery Information:
To use DRM, register the DRM license by entering the following:
register license file=drm.lic
For more information, see Registering Licensed Features.
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.
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. |
backup stgpool backuppool cstoragepf
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.
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 |
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
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.
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:
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:
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:
c:\win32app\ibm\adsm\server2 \prepare\LOGANDDB.VOLUMES.INSTALL.CMD c:\win32app\ibm\adsm\server2 \prepare\COPYSTGPOOL.VOLUMES.AVAILABLE.MAC c:\win32app\ibm\adsm\server2 \prepare\COPYSTGPOOL.VOLUMES.DESTROYED.MAC
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 |
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):
query rpfile devclass=*
TSM displays a list of all recovery plan files that have been saved for the source server on target servers.
query rpfile nodename=*
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=rpfileThe 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.
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):
query rpfcontent marketing.19990901.043900 devclass=targetclass
query rpfcontent marketing.19990831.045000 nodename=branch8
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. |
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:
query rpfcontent marketing.19990831.045000 devclass=targetclass > rpf.out
query rpfcontent marketing.19990831.045000 nodename=branch8 > 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
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:
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/1999To 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.
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 |
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. |
define machine mach22 building=021 floor=2 room=2929 priority=1
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.
The following partial output is from a query on an AIX client machine.
+--------------------------------------------------------------------------------+ |--1 Host Name: mach22 with 256 MB Memory Card | |--- 256 MB Memory Card | |--- | |--4 Operating System: AIX Version 4 Release 3 | |--- | |--- Hardware Address: 10:00:5x:a8:6a:46 | +--------------------------------------------------------------------------------+
Characteristics and recovery instructions are specified with separate INSERT MACHINE commands:
insert machine mach22 1 characteristics="Host Name: mach22 with 256 MB Memory Card" insert machine mach22 2 characteristics="Operating System: AIX Version 4 Release 3"
insert machine mach22 1 - recoveryinstructions="Recover this machine for accounts receivable dept."
To help automate the adding of client machine information, a sample VBScript command procedure named machchar.vbs is shipped with DRM. The following example shows how to use a local program to add machine characteristics or recovery instructions.
From an AIX prompt, issue the following commands:
echo "devices" > clientinfo.txt lsdev -C | sort -d -f >> clientinfo.txt echo "logical volumes by volume group" >> clientinfo.txt lsvg -o | lsvg -i -l >> clientinfo.txt echo "file systems" >> clientinfo.txt df >> clientinfo.txt
The file, clientinfo.txt, from the AIX client machine is transferred to a Windows NT machine that has an administrative command-line client installed. The file is then processed by the VBScript command procedure, which builds a macro of INSERT commands (one command for each line in the file). Figure 86 is an example procedure named machchar.rex to insert machine characteristics.
Figure 86. Example of VBScript Command Procedure to Insert Machine Characteristics
'***************************************************************************
' Tivoli Disaster Recovery Manager for Windows NT/2000 Sample Script
'
' Read machine characteristics from an input file and build an output file
' that is an TSM macro. The TSM macro contains statements which are
' TSM commands to insert client machine information into the ADSM server
' database. The TSM macro is used with the TSM administrative client.
'
' Invoke with:
' cscript machchar.vbs machinename inputmachinefilename outputmacrofilename
' where:
' machinename is the name of a machine that has previously
' been defined to the TSM server with the
' DEFINE MACHINE command
' inputmachinefilename is the name of the input file which contains
' the client machine characteristics. This file
' would typically be built on the client machine
' then the file would be transferred to the
' Windows NT machine where the TSM Administrative
' client is installed.
' outputmacrofilename is the name of the output file in an existing
' directory which will be the TSM macro. The
' TSM macro will consist of a series of commands
' to insert machine characteristics into the TSM
' server database. For example:
'
' INSERT MACHINE mch1 n characteristics='xxx...'
'
' where:
' n represents the sequence number
' this line will have in the
' TSM server database
' 'xxx...' represents a single line from
' the input file
'
' NOTE: The maximum length of a line of machine
' characteristics is 1024
'
' Example usage:
' cscript machchar.vbs mch1 c:\client1\clientinfo.txt c:\client1\clientinfo.mac
'***************************************************************************
Dim args
Dim MACHINENAME, INFILE, OUTFILE
dim fso dim fo, fi
dim SEQUENCE
Dim CRLF
CRLF = Chr(13) & Chr(10)
Const ForReading = 1, ForWriting = 2
'***************************************************************************
' Get input arguments: MACHINENAME =machinename
' INFILE =inputmachinefilename
' OUTFILE =outputmacrofilename
'***************************************************************************
set args = Wscript.Arguments
If args.Count < 3 Then
Wscript.Echo _
"usage: cscript machchar.vbs machinename inputmachinefilename outputmacrofilename" & CRLF & _
"example: cscript machchar.vbs mch1 c:\client1\clientinfo.txt c:\client1\clientinfo.mac"
Wscript.Quit(1)
Else
MACHINENAME = args.Item(0)
INFILE = args.Item(1)
OUTFILE = args.Item(2)
End if
Set fso = CreateObject("Scripting.FileSystemObject")
'***************************************************************************
' Create the TSM macro file.
'***************************************************************************
Set fo = fso.OpenTextFile(OUTFILE, ForWriting, True)
Wscript.Echo "Creating TSM macro file: " & OUTFILE
'***************************************************************************
' Place an TSM command in the TSM macro to delete any existing machine
' characteristics for this machine from the TSM server database.
'***************************************************************************
fo.WriteLine "delete machine " & MACHINENAME & " type=characteristics"
'***************************************************************************
' Read a line from the input machine characteristics file, add the TSM
' command to insert the line of machine characteristics into the TSM server
' database, and write the result to the output TSM macro.
'***************************************************************************
SEQUENCE = 1
Set fi = fso.OpenTextFile(INFILE, ForReading, False)
Do While fi.AtEndOfStream <> True
INLINE = fi.ReadLine
fo.WriteLine "insert machine " & MACHINENAME & " " & SEQUENCE & " char='" & INLINE &"'"
SEQUENCE = SEQUENCE + 1
Loop
'***************************************************************************
' Close the files.
'***************************************************************************
fo.Close
fi.Close
The machchar.rex VBScript command procedure is run:
cscript machchar.vbs acctsrecv clientinfo.txt clientinfo.mac
The macro is then run to load the data into the database.
> dsmadmc -id=xxx -pw=xxx macro clientinfo.mac
You can view your machine characteristics by issuing the QUERY MACHINE command with FORMAT=CHARACTERISTICS parameter.
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.
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.
The following example associates machine MACH255 with recovery media tellerwrkstnimage:
define recmedmachassociation tellerwrkstnimage mach255
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