Part 1

It’s clear why testing is important, but how to actually test your disaster recovery plan probably isn’t so clear. Here’s where to start – check out part 2 for where to go from here.

First Step: The In-House Essentials

Let’s assume you already have a disaster recovery plan (DRP) in place, which you established when you first invested in disaster recovery services. Many companies underestimate how much their business environment changes in a year, or even just a few months – from new clients and servers, or even just new computers. You would be surprised how easy it is for slight changes like these to result in holes in your disaster recovery plan.

Sit down with members from each department and make sure that every aspect of your plan is still current, and that the right applications and data are prioritized. For instance, at Protos Technologies our engineers conduct pre-test conference calls to ensure that no servers are neglected if they were added or modified since your plan was made.

If a recent Business Impact Analysis (BIA) was performed, this should also be consulted and discussed. Consider this like a card game or a tabletop exercise – you draw a card, and it reveals a scenario like “hardware failure” or “partial server failure”. What do you do? As you go through each scenario, try to find gaps, bottlenecks, or places where something could go wrong. This also gives your staff a good working knowledge of your DR plan overall.

Consider each of the following questions:

• Does your plan account for partial server loss?
• Are any applications dependent on one another?
• Are your business-critical requirements being addressed?
• Do applications need to be restored in any particular order?
• Has your plan adjusted for growth that has taken place since it was established?
• Has your plan adjusted for changes in business processes, clientele or personnel?
• Do members of each department agree on the prioritization of particular applications?
• Are there any processes that are not covered or prioritized which could bring your business to a halt if they failed?

Second Step: The Third-Party’s Responsibility

Many disaster recovery providers might suggest something called the “The Full Interruption Test” – a costly, disruptive, and risky procedure that essentially fabricates a disaster scenario to test your DR plan. Unlike other companies, at Protos Technologies we test in a way that keeps your data and workflow uninterrupted and secure at all times. Our managed disaster recovery plan testing does not interrupt business operations or production, and cannot in any way affect or influence the production site. We believe that every DR provider should have the same responsibility when testing your systems.

Click here for the second part of this article, where we give you all of the insider, technical details on how your systems can be tested in a way that doesn’t affect your workflow.

The Problems You Will Encounter

Problems found in the in-house stage of the testing process are primarily related to human error. More often than not, companies find that their plans are out of date, critical servers or applications slipped through the cracks, or co-dependent applications weren’t taken into account. Although this might seem worrisome, it’s actually a good thing; this means that these problems will be fixed before a real disaster happens.

There’s no way of knowing whether your disaster recovery plan meets your business requirements without a real disaster, or a test. Think of it this way: time spent testing is time saved from downtime. That’s why we treat disaster recovery plan testing as an integrated part of our recovery solutions.

For more information on how to test your disaster recovery plan, contact us today at 317-707-3941.