Ezine

This article can also be found in the Premium Editorial Download "Storage magazine: Comparing EMC Symmetrix DMX-3 vs. Hitachi Data Systems USP1100."

Download it now to read this article plus other related content.

No testing, no DR
The planning part of DR is relatively easy compared to testing the plan. Testing is the part of DR that's often dreaded and, unfortunately, too often avoided. Yet without proper testing, one might as well not bother with the planning because the likelihood of successful execution is small.

Some fundamental considerations for testing include:

  • Test application recovery, not just data recovery (think application interdependency)
  • Let nonprimary individuals perform the recovery to validate procedures and documentation
  • Construct multiple disaster scenarios and employ role-playing
  • Establish a positive DR mindset: uncovering (and fixing) problems is a good thing
  • Track metrics to measure and chart improvement
The most common reason given for not doing more extensive testing is cost. This will inevitably be a point of contention because DR testing is viewed as an exception to what are commonly thought of as day-to-day operations. The only way to effectively address this issue and justify the cost is by closely linking the testing process to RTO/RPO service-level objectives. This means the DR business case, particularly the financial impact of RTO/RPO, must be accurate and complete. The message should be that comprehensive testing is an essential requirement to ensuring that those metrics can actually be met and is an integral part of the recovery process.

    Requires Free Membership to View

    Login

This was first published in January 2007

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top