Building a testing plan from the disaster recovery (DR) plan is often not the easiest task.  Looking past the simple “which workloads are critical?” discussions, DR testing is where “the rubber meets the road” and you put the plan through its measures.  So, you need to be certain that what you’re testing will adequately represent both the intent and the proper execution of the plan.

In many cases, testing gets minimized down to either a high-level overview or simulations of only a portion of the environment, lacking the appropriate representation of what will actually transpire in a real disaster scenario.

And that’s a problem.

If this is you, your DR test plan is missing its opportunity to give IT the confidence that, should operations cease, they can definitely get the environment back up and running in accordance with recovery objectives.

So, why is your plan lacking what’s necessary to properly test the DR plan? There are three reasons:

  1. Your Testing Plan is Too Technical – Sure, your plan absolutely needs to spell out the specific technical steps necessary. But testing DR isn’t just about the process of restoring a backup; it needs to be designed to meet the operational needs of the business as well as the recovery needs based on the hardware, software, virtualization, etc. you have available.
  2. It’s Not Technical Enough – Thinking in the opposite direction, most testing plans focus on recovering a single server, a particular data set, or a critical workload. But your testing plan also needs to include the testing of users connecting to the set being recovered, testing out the process of using a cloud-based recovery site (if applicable), failover, failback.  If your testing plan strictly covers basic recovery, you need to expand your scope.
  3. It’s not disaster-specific – Restoring a server is great, but what if the disaster is something bigger?  For example, a loss of location would require much more recovery efforts that the single server or application. As you plan out your DR testing, you should be doing so in the context of specific losses that include the loss of data, application, system, workload, and location – and to use the testing to know that you can recover operations in the face of any level of loss.

By expanding the way you think about what needs to be included in your DR testing to meet the organization’s needs, you can make certain that IT has the ability, experience, and institutional knowledge of what’s necessary to recover some of your organization’s environment.