DB2 backup and disaster recovery

Redo, undo, and why copies exist

The log is necessary but not sufficient for media recovery. If a VSAM data set is gone, there is nothing to apply redo to until you restore a copy. If you only need to reverse recent committed work on a healthy object, backout (RECOVER BACKOUT YES to a PIT) can skip the restore. Restart after a crash undoes inflight URs and redoes committed pages that never reached disk—no COPY involved.

Beginners hear “undo” and think ROLLBACK. Application ROLLBACK is undo of the current UR. Recovery undo is the same logging idea at utility or restart scale.

Image copies

Full image copies are the simple restore base. Take them on a cadence that matches how long you can afford LOGAPPLY to run. Incremental image copies shrink the backup window when few pages change; RECOVER must merge full + incrementals. MERGECOPY (or COPYTOCOPY) can turn a chain into a new full so recovery stays fast.

COPY can write local copies and recovery-site copies (RECOVERYDDN) in one run so the DR vault gets a tape without a second read of the table space. Dual independent output is as important as dual logging.

SHRLEVEL REFERENCE versus CHANGE

SHRLEVEL REFERENCE allows readers; writers wait. The copy is consistent as of the copy. SHRLEVEL CHANGE allows updates; the copy is “fuzzy.” RECOVER always applies log from the copy START_RBA, so current recovery is still consistent. For PIT, recover to a log point, not blindly TOCOPY of a CHANGE copy, if you need transactional consistency without extra thought.

The COPY utility

COPY is the workhorse. It registers rows in SYSCOPY (ICTYPE F or I). Typical control:

1
2
3
4
5
6
7
8
9
10
11
12
COPY TABLESPACE HRDB.EMPTS
  COPYDDN(LOCALDD)
  RECOVERYDDN(REMOTDD)
  FULL YES
  SHRLEVEL CHANGE
  PARALLEL
  CHECKPAGE;
 
COPY TABLESPACE HRDB.EMPTS
  COPYDDN(INCRDD)
  FULL NO
  SHRLEVEL CHANGE;

• FULL YES — full image copy; FULL NO — incremental
• DSNUM — partition or piece
• CONCURRENT / FlashCopy options — dataset FlashCopy image copies
• CHECKPAGE — validate pages while copying
• LISTDEF / TEMPLATE — modern lists and dynamically named output data sets

Indexes are COPY YES (you COPY them) or COPY NO (you REBUILD after table recovery). Copying the table and not planning index rebuild/copy is an incomplete backup design.

After COPY, QUIESCE is optional but valuable: a SYSCOPY consistency point for PIT of a table space set. COPY itself does not replace QUIESCE for RI sets.

BACKUP SYSTEM and FlashCopy volumes

Object COPY does not snapshot the catalog, BSDS, and logs as one atomic system. BACKUP SYSTEM invokes DFSMShsm to FlashCopy the SMS copy pools you defined (typically a database copy pool and a log copy pool) for a subsystem or data sharing group. History is stored in the BSDS. Restrictions: SMS-managed data sets; no failed abnormally quiesced members in the group; SYSCTRL/SYSADM.

RESTORE SYSTEM restores the latest system-level backup before a log truncation point you set with DSNJU003, then applies log. You cannot pick an arbitrary old version by name the way you pick an image copy—plan version retention in HSM.

A related pattern: -SET LOG SUSPEND (quiesce 32 KB writes and extensions, freeze logging), FlashCopy all Db2 volumes including ICF catalogs, active logs, and BSDS, then SET LOG RESUME. For data sharing, SUSPEND each member. Recovery is restore volumes, start members, recover GRECP/LPL as needed. This is classic DASD-level DR.

Disaster recovery practice

A remote site needs:

• BSDS copies (dual) and a print log map
• Archive logs through the intended truncation RBA/LRSN
• Image copies or system-level / volume backups
• ICF user catalogs and the procedure to start Db2 (and CF structures for data sharing)
• A written order: restore volumes or RESTORE SYSTEM, conditional restart, GRECP, verify

Object-level RECOVER at DR works only if every needed SYSCOPY dataset and archive is there. System-level backup is usually faster for “the whole LPAR is gone.” Mix them: daily BACKUP SYSTEM plus more frequent COPY of critical table spaces.

Test restores. An untested RECOVERYDDN tape is not a backup. Clock-skew, 10-byte RBA format, and encryption keys kill DR weekends.

Operational habits

• Full copies on a cycle; incrementals between if volume justifies merge cost
• COPY after REORG/LOAD REPLACE so you are not applying a giant log tail
• Do not MODIFY RECOVERY before the copy and archives have left the building
• Monitor COPY failures and COPY pending (COPY status) on table spaces
• Keep local and remote copies on different failure domains

Explain It Like I'm Five

An image copy is a photo of the castle. A full photo shows every brick. An incremental photo shows only the bricks you moved since the last photo. Redo is following the diary (the log) to add the bricks you placed after the photo. Undo is taking bricks off because that part was never glued (not committed) or because you decided to go back to Friday. Disaster recovery is keeping a second photo album and diary at grandma’s house in case your house floods. COPY takes the photos. BACKUP SYSTEM photocopies the whole room.

Exercises

1. Write a COPY FULL YES SHRLEVEL CHANGE job for a test table space with COPYDDN and RECOVERYDDN.
2. Query SYSCOPY for that object and identify ICTYPE F versus I rows.
3. Explain why RECOVER after SHRLEVEL CHANGE still needs archive logs even if you have a full copy from this morning.
4. Compare BACKOUT YES PIT to restore + LOGAPPLY for a table that was not physically damaged.
5. List the copy-pool and BSDS items you would confirm before calling BACKUP SYSTEM “DR ready.”