November 18, 2008

Disaster Recover Planning Takes Different Forms

Have you ever been asked to define a backup and recovery strategy for your DB2 subsystem? Or was your task was something smaller, like developing a recovery strategy for the DB2 tables used in a given application within your business area? The process of planning for an entire system failure and recovery versus individual application failures and recovery are similar, yet very different.

If you've planned for onsite and offsite disaster recovery (DR), you know how much work goes into ensuring that your systems can be back running as quickly as possible in response to an unplanned outage. Even though the recovery itself can be simple (e.g., restoring one table due to a program changing the wrong data, restoring a volume due to hardware failure or restoring an entire subsystem at a remote site because a disaster took out the local data center), developing a DR plan still takes time, preparation and testing.

The IBM Redpaper, "DB2 9 for z/OS: Backup and Recovery I/O Related Performance Considerations," provides a nice overview of the terminology, concepts and hardware technology available to help ensure a timely recovery. The document features a review of disk considerations and ways to configure IBM System Storage DS8000 series disk systems. Tape technology and data mirroring, and how these technologies impact recovery time, are also reviewed. In addition, the Redpaper examines different strategies for system-wide backup and recovery and the factors that affect recovery time. The final section goes into different workload failure scenarios and the processes of recovering to both current and prior points in time.

Whether your responsibility is system-wide or application-specific backup and recovery, give this Redpaper a read. It's suited for both DB2 systems programmers and application DBAs.

My own DB2 recovery recommendations can be boiled down to this:

Step 1--Plan for the different scenarios.
Step 2--Practice actual recovery for all scenarios.
Step 3--Update the plan as you practice, and document everything.

Think of disaster recovery planning as a fire drill. You must know what to do long before the alarm goes off for real.