Preparing for disaster recovery

The method involves shipping image copies and archive logs offsite and planning a recovery to the point in time that corresponds to the end of the last shipped archive log.

To prepare for disaster recovery, begin by identifying a set of critical objects that must be recovered first. One approach is to plan on running as many concurrent recoveries as possible. To do so, you can divide the table spaces among the BMC AMI Recover jobs so that each job finishes in approximately the same time, reducing the overall elapsed time. You can group the objects in change accumulation groups to correspond to their grouping for recovery. You may want to use the same groups that you use for local recoveries. In this case, each BMC AMI Recover job would probably read several change accumulation files.

You could create additional change accumulation groups solely to support offsite recovery. In this case, each BMC AMI Recover job would read one change accumulation file. The use of change accumulation files instead of archive logs allows the concurrent execution of many recoveries.

The use of change accumulation files by BMC AMI Recover depends on the existence of repository data. To prepare for offsite shipment of change accumulation files, you must make an image copy of the R+/CHANGE ACCUM repository (SHRLEVEL REFERENCE) after each set of R+/CHANGE ACCUM runs. Because the repository is a very small table space that is not heavily updated, making the image copy should not be an expensive operation. You can ship the image copy file offsite with the change accumulation files.

At the recovery site, the sequence of events is as follows:

1. Restore any necessary system and Db2 libraries.

   You must restore the MVS catalog entries for any change accumulation files to be used.

2. Restore the archives and BSDS, a perform change log inventory, define the active log data sets, and so on.

3. Start Db2 and recover the catalog and directory.

4. Recover the repository table space, to the copy that was shipped with the last set of change accumulation files or to the 'current' time.

   Rebuild all indexes that are defined for the repository if the table space recovery did not include indexes.

5. Run the concurrent BMC AMI Recover jobs, with each job reading one or more change accumulation files and the latest image copy for each space.

   This process should reduce the elapsed time necessary to recover your critical application spaces. When the critical objects are running, you can recover your other spaces.