System-Level Backup and Recovery

DB2 version 8 provides more usability, flexibility, and faster recovery by allowing for system-level backup and recovery. This technology may be useful for disaster recovery and subsystem cloning.

The feature is implemented with two new utilities, BACKUP SYSTEM and RESTORE SYSTEM. The utilities perform the backups and restores of volumes defined to a COPYPOOL in hierarchical storage manager (HSM) and SMS. The COPYPOOL is a set of SMS groups that can be backed up and restored in a single command. This capability was introduced in z/OS 1.5 and invokes new HSM services to back up and restore subsystems.

Every subsystem will define two COPYPOOLs: one for data and one for logs. HSM and SMS will determine which volumes belong to the COPYPOOL and are needed for backup/restore.

The database COPYPOOL should contain volumes of associated databases and ICF catalogs. The log COPYPOOL should contain volumes with BSDS, active logs, and ICF catalogs.

Two methods are used for performing the copies and restores.

  1. A FULL copy will copy the database and log COPYPOOLs; then these copies can be used to recover the entire system, using normal restart recovery or with the RESTORE SYSTEM utility.

  2. A DATA ONLY copy will copy on the database COPYPOOL. These copies can be used with the RESTORE SYSTEM utility to recover the system to a point in time.


The RESTORE SYSTEM utility can be executed from any member in a data sharing group.

After the RESTORE SYSTEM is complete, objects that are in recovery-pending (RECP) or rebuild-pending (RDBP) status will need to be recovered. These objects may include ones affected by a REORG or LOAD with LOG NO after the last copy was taken.

Two options can be used to back up the entire subsystem. One is the BACKUP SYSTEM FULL option, which copies both log and database SMS storage groups. Restoration can then be done, using normal DB2 restart recovery.


DB2 logs and their ICF catalogs should be in the same SMS storage group.

The other option, BACKUP SYSTEM DATA ONLY, copies only database storage groups. The RESTORE SYSTEM utility may be used to recover the system to an arbitrary point between system copies.


ICF catalogs for databases should be separate and reside with the data.

DSNJU003 (change log inventory) can be used to create a conditional restart control record to truncate the logs at the desired point in time:


The same PIT can be used for each member of the data sharing group. When restarting DB2, DB2 will enter System Recover Pending mode, and every DB2 member of a data sharing group must be restarted. At this point, you must run the SYSTEM RESTORE utility and then stop DB2 to reset the System Recover Pending mode. For data sharing, all members must be stopped. Then a start DB2 can be performed.

DB2 for z. OS Version 8 DBA Certification Guide
DB2 for z/OS Version 8 DBA Certification Guide
ISBN: 0131491202
EAN: 2147483647
Year: 2003
Pages: 175
Authors: Susan Lawson © 2008-2017.
If you may any questions please contact us: