Creating essential disaster recovery elements

You must take steps to create essential disaster recovery elements. For example, you must determine how often to make copies and send them to the recovery site.

To create essential disaster recovery elements:

1. Make image copies:
   1. Make copies of your data sets and Db2 catalogs and directories.

      Use the COPY utility to make copies for the local subsystem and additional copies for disaster recovery. You can also use the COPYTOCOPY utility to make additional image copies from the primary image copy made by the COPY utility. Install your local subsystem with the LOCALSITE option of the SITE TYPE field on installation panel DSNTIPO. Use the RECOVERYDDN option when you run COPY to make additional copies for disaster recovery. You can use those copies on any Db2 subsystem that you have installed using the RECOVERYSITE option.

      Tip: You can also use these copies on a subsystem that is installed with the LOCALSITE option if you run RECOVER with the RECOVERYSITE option. Alternatively, you can use copies that are prepared for the local site on a recovery site if you run RECOVER with the option LOCALSITE.

      Important: Do not produce copies by invoking COPY twice.
   2. Optional: Catalog the image copies if you want to track them.
   3. Create a QMF report or use SPUFI to issue a SELECT statement to list the contents of SYSCOPY.
   4. Send the image copies, and report to the recovery site.
   5. Record this activity at the recovery site when the image copies and the report are received.

      All table spaces should have valid image copies. Indexes can have valid image copies or they can be rebuilt from the table spaces.

2. Make copies of the archive logs for the recovery site:
   1. Use the ARCHIVE LOG command to archive all current Db2 active log data sets.
      Important: Do not use striped active logs for disaster recovery.

      Recommendation: When using dual logging, keep both copies of the archive log at the local site in case the first copy becomes unreadable. If the first copy is unreadable, Db2 requests the second copy. If the second copy is not available, the read fails.

      However, if you take precautions when using dual logging, such as making another copy of the first archive log, you can send the second copy to the recovery site. If recovery is necessary at the recovery site, specify YES for the READ COPY2 ARCHIVE field on installation panel DSNTIPO. Using this option causes Db2 to request the second archive log first.

   2. Optional: Catalog the archive logs if you want to track them.

      You will probably need some way to track the volume serial numbers and data set names. One way of doing this is to catalog the archive logs to create a record of the necessary information. You can also create your own tracking method and do it manually.

   3. Use the print log map utility to create a BSDS report.
   4. Send the archive copy, the BSDS report, and any additional information about the archive log to the recovery site.
   5. Record this activity at the recovery site when the archive copy and the report are received.
3. Choose consistent system time:
   Important: After you establish a consistent system time, do not alter the system clock. Any manual change in the system time (forward or backward) can affect how Db2 writes and processes image copies and log records.
   1. Choose a consistent system time for all Db2 subsystems.

      Db2 utilities, including the RECOVER utility, require system clocks that are consistent across all members of a Db2 data-sharing group. To prevent inconsistencies during data recovery, ensure that all system times are consistent with the system time at the failing site.

   2. Ensure that the system clock remains consistent.
4. Back up integrated catalog facility catalogs:
   1. Back up all Db2-related integrated catalog facility catalogs with the VSAM EXPORT command on a daily basis.
   2. Synchronize the backups with the cataloging of image copies and archives.
   3. Use the VSAM LISTCAT command to create a list of the Db2 entries.
   4. Send the EXPORT backup and list to the recovery site.
   5. Record this activity at the recovery site when the EXPORT backup and list are received.
5. Back up Db2 libraries:
   1. Back up Db2 libraries to tape when they are changed. Include the SMP/E, load, distribution, and target libraries, as well as the most recent user applications and DBRMs.
   2. Back up the DSNTIJUZ job that builds the ZPARM and DECP modules.
   3. Back up the data set allocations for the BSDS, logs, directory, and catalogs.
   4. Document your backups.
   5. Send backups and corresponding documentation to the recovery site.
   6. Record activity at the recovery site when the library backup and documentation are received.