Previous Topic: Quick System Availability with Partial RecoveryNext Topic: Detailed Backup and Recovery Steps

Backup and Recovery › Sample Backup and Recovery Procedures › Quick Availability, Recovery of Previous Change

Quick Availability, Recovery of Previous Change

This approach is an alternative if you cannot afford downtime while complete recovery is done. It is a variation of the previous section, Quick System Availability With Partial Recovery. To use this method, IPL CA ACF2 for VM immediately on the alternate databases and recover later, when downtime is affordable or when it will not have a great impact. Instead of attempting complete recovery of all changes since the backups, which will not work for records updated after the problem, recovery only uses SMF records between the time of the backup used to build the alternate database and when the problem occurred.

This approach's advantage is that, after the problem occurs, only an IPL will activate operations. Also, because complete recovery cannot be done in this case, lost data is limited to changes done while on the alternate databases. You can notify users with a LOGMSG that any password or other changes to the CA ACF2 for VM databases are lost until further notice. The disadvantage is that you cannot recover all of the databases with this approach.

Recovery Steps

When the problem is a hardware error or corrupted databases, follow these steps for recovery:

  1. Restore the latest backups to the alternate databases. Skip this step if you use the post backup service machine to restore backups to the alternate databases after each backup occurs. Verify that the automatic restore did occur correctly. We recommend that you use the post backup service machine to do the automatic restores.
  2. Record the date and time to use later in selecting the SMF records for recovery.
  3. Issue a LOGMSG (or equivalent) notifying users that changes to CA ACF2 for VM are lost until further notice.
  4. IPL the system using the alternate databases.

When the primary databases are available and you have time, follow these steps:

  1. IPL the system without starting CA ACF2 for VM (NOAUTO mode).
  2. If the databases are corrupted, make a DDR copy of the primary databases for debugging purposes.
  3. Restore the latest backups to the primary databases. This restore step is done to the PRIMARY databases, not the alternates.
  4. Identify the SMF files needed for recovery. You must use current (online) SMF disks. They are volatile because a SMF disk can become active and reused for recording at any time unless the system has been IPLed in NOAUTO mode.
  5. Run the ACFRECVR utility to merge database changes from the SMF records to the primary databases. For more information on this utility, see the Reports and Utilities Guide. This recover step applies to the PRIMARY databases, not the alternates. Use the recover options to limit the start and end range of dates and times to prevent the utility from using SMF records created after the problem occurred.
  6. IPL CA ACF2 for VM normally (defaults to the primary databases).
  7. Manually back up the CA ACF2 for VM databases using the ACFSERVE BACKUP command.
  8. Restore the backups just taken to rebuild the alternate databases (or let the post backup service machine rebuild the alternate databases).