The Redbook is in 5 parts:

• Part 1: The Whole Picture: Business Continuity and Disaster Recovery
• Part 2: Disaster Recovery Major Components
• Part 3: General Solutions for Disaster Recovery
• Part 4: Implementing Disaster Recovery Scenarios
• Part 5: Additional Considerations

The following is a description of each of the 5 Parts of the redbook.

Part 1: The Whole Picture: Business Continuity and Disaster Recovery

Business Continuity (BC) and Disaster Recovery (DR) act at different levels in the organization.

BC is the strategy at the enterprise level, while DR is the solution at the IT level. The BS 7799 (British Standard -Information technology - Code of practice for information security management) has generically defined the objective of business continuity management as: To counteract interruptions of business activities and to protect critical business processes from the effects of major failures or disasters. This definition has been adopted by ISO as ISO/IEC 17799:2000. Here are some references for these topics:

• For BS7799: http://www.bsi.org.uk or http://www.bsi-global.com/index.xalter
• For ISO/IEC 17799: http://www.iso.org

DR is the process that must be activated following a disaster for the purpose of restoring information services in the anticipated manner and time. Such a process manages and resolves a contingent situation (a disaster recovery plan is a particular “contingency plan”). It includes the procedures necessary for the restoration of the data and the network, and has, as its ultimate purpose, the reactivation of the operability of the users of information services. It must describe how, where, and when the user will resume working activities.

The following chart positions Business Continuity and Disaster Recovery.

RPO, RTO, and NRO

Two very commonly used terms used to qualify the recovery solutions are now Recovery Point Objective (RPO) and Recovery Time Objective (RTO). These terms have replaced the former possibly more intuitive terms lost data and downtime. They are complementary and both must be considered when evaluating a disaster recovery solution. The enterprise's requirements for minimizing downtime and lost data vary by application and are determined by the cost to the organization of these two factors.

Another term encountered now is Network Recovery Objective (NRO). This can be studied in the SHARE presentation: “Cost Effective Disaster Recovery: How Much Can You Afford”: http://ew.share.org/proceedingmod/abstract.cfm?abstract_id=3011&conference_id=1

The Tiers of Disaster Recovery

SHARE has defined 7 tiers of Disaster Recovery to help companies decide where they stand, and where they want to be. The higher the tier, the higher the cost and investment, and the quicker the RTO and usually the later RPO.

• Tier 0-No disaster recovery (DR) plan
• Tier 1-Pickup Truck Access Method
• Tier 2-PTAM and hot site
• Tier 3-Electronic vaulting
• Tier 4-Active secondary site (electronic remote journaling)
• Tier 5-Two site two-phase commit
• Tier 6-Zero data loss (remote copy)

Tiers can also be studied in the SHARE presentation: “Cost Effective Disaster Recovery: How Much Can You Afford”: http://ew.share.org/proceedingmod/abstract.cfm?abstract_id=3011&conference_id=1

Return On Investment

In order to assess the cost of your DR solution, there are questions that need to be answered.

·        What level of data currency is required?

·        Can the data at the disaster site be a few seconds, minutes, or hours old?

·        How consistent is the data expected to be?

·        Multiple table consistency?

·        Transaction consistency?

·        Subsystem-wide consistency? (A very high degree of data consistency will have a substantial cost in recovery time and resources.)

·        When would this solution be rolled out?

·        When would all of the hardware and software need to be available?

·        When can the needed hardware and software levels be installed?

Lessons Learned From 9/11

The events of September 11, 2001 in the United States of America have underlined how critical it is for businesses to be ready for disasters. The Federal Reserve, the Office of the Comptroller of the Currency, the Securities and Exchange Commission, and the New York State Banking Department (the agencies) have met with industry participants to analyze the lessons learned from the events of September 11. The agencies have released an interagency white paper on sound practices to strengthen the resilience of the US financial system. For more information on this, refer to: http://sec.gov/news/studies/34-47638.htm .

The following list is a summary of lessons learned about IT service continuity:

• Geographical separation of facilities and resources is critical to maintaining business continuity. Any resource that cannot be replaced from external sources within the RTO should be available within the enterprise, in multiple locations. This not only applies to buildings and hardware resources, but also to employees and data, since planning employee and data survival is very critical. Allowing staff to work out of a home office should not be overlooked as one way of being DR ready.
• Depending on the RTO and RPO (RTO and RPO are typically expressed in hours  or minutes) it may be necessary for some enterprises to implement an in-house DR solution. If this is the case, the facilities required to achieve geographical separation may need to be owned by the enterprise.
• The installed server capacity at the second data center can be used to meet normal day-to-day data processing needs and fallback capacity can be provided either by prioritizing workloads (production, test, development, data mining) or by implementing capacity upgrades based on changing a license agreement, rather than by installing additional capacity. Disk resources need to be duplicated for disk data that is mirrored.
• Recovery procedures must be well documented, tested, maintained, and available after a disaster. Data backup and/or data mirroring must run like clockwork all the time.
• It is highly recommended that the DR solution be based on as much automation as possible. In case of a disaster, key skills may not be available to restore IT services.
• An enterprise's critical service providers, suppliers, and vendors may be affected by the same disaster, therefore, enter into a discussion with them about their DR readiness.
• The recovery plan should also cover the following aspects:
• Extensive loss of communication lines
• Total loss of data on desktops and laptops
• Public transport breakdown

DB2 Disaster Recovery

This chapter introduces the options and features available for a DB2 subsystem DR solution. Topics covered are:

·        Introduction to DB2 disaster recovery solutions

·        DR solutions in terms of RTO and RPO

·        Data consistency

·        DB2’s disaster recovery functions

·        Determining the RBA for conditional restarts

·        Actions to take when there are active utilities

The following chart shows some of the solutions, and positions them in terms of data loss against recovery time:

These solutions are described in detail in Chapter 2 of the redbook.

Data consistency and the “Rolling Disaster”

ESS Copy Services provide data mirroring capability providing the automatic replication of current data from your primary site to a secondary site. The secondary site allows you to recover your data after a disaster without the need to restore DB2 image copies or apply DB2 logs to bring DB2 data to the current point-in-time.

Notice that the scenarios and procedures for data mirroring are intended for environments that mirror an entire DB2 subsystem or data sharing group, including DB2 catalog, directory, user data, BSDS, and active logs. You must mirror all volumes in such a way that they terminate at exactly the same point.

A rolling disaster is the typical real disaster, where your local site gradually and intermittently fails over a number of seconds. The various components fail in sequence. For example, if a data volume failed to update its secondary, yet the corresponding log update was copied to the secondary, this would eventually result in a secondary copy of the data that is inconsistent with the primary copy. The database would need to be recovered from image copies and log data. In all cases, notification of this miss must be known at secondary. When this happens for hundreds of volumes, without a clear notification of status of impacted secondary volumes, recovery can be extremely complex and long.

When using data mirroring for disaster recovery, you must mirror data from your local site with a method that does not reproduce a rolling disaster at your recovery site. To recover DB2 with data integrity, you must use volumes that end at a consistent point-in-time for each DB2 subsystem or data sharing group. Mirroring a rolling disaster causes volumes at your recovery site to end over a span of time rather than at one single point.

In a disaster (think of flood, fire, and explosion), it is very likely that different logical storage subsystems fail at different times. It is also true that for each SQL UPDATE, INSERT, and DELETE issued by an application, DB2 will issue, at different times, several dependent writes on log data sets, table spaces, and index spaces allocated to DASD volumes spread across several LSSs. While the write to the log is externalized at commit time, the write to table spaces and index spaces are externalized when the buffer pool thresholds are reached for each page set in each buffer pool.

The redbook explains in detail, with examples, how the rolling disaster occurs, and how to design for them using Consistency Groups. A consistency group is a collection of volumes that contain consistent, related data. This data can span logical storage subsystems and disk subsystems. For DB2 specifically, a consistency group contains an entire DB2 subsystem or a DB2 data-sharing group. The following DB2 elements comprise a consistency group:

·        BSDS

·        Active Logs

·        DB2 Catalog

·