The importance of disaster recovery testing can’t be overstated.

It’s one thing to have a DR plan in place. It’s a whole different ballgame to execute that plan flawlessly because so much can go wrong in the eye of the storm.

You might encounter an issue and have no idea who to call. You might have a name and number, but then you realize in the middle of the crisis that the individual no longer works for your company. These are just some of the issues which could arise in a disaster. If you’re missing even a single piece of key information, you might not be able to bring up your production workloads in your recovery environment.

If you haven’t tested your plan, you’ll have no idea if you’ll encounter these kinds of issues in a real disaster situation. With thorough testing, you can unearth these problems and make alterations ahead of time to hopefully avoid derailing your recovery.

But testing alone is not enough. It must be done the right way to be effective. Many companies test frequently, but their tests are incomplete, lack rigor, or breeze over scenarios. This kind of testing is almost as ineffective as not testing at all.

Whether you’ve never tested your plan, your DR testing needs to get back on track, or you simply want to confirm that your testing is up to par. Here’s everything you need to know about DR testing.

What businesses get wrong about DR testing

How much confidence do you have in your DR capabilities and plans? If you’re performing tests regularly, you’ve likely built proficiency, which breeds confidence. Yet, that confidence doesn’t guarantee the plan will work at the time of a disaster.

What matters – and what will determine the success of your recovery – is how close your testing is to an actual disaster. Many companies fail to challenge themselves on all the programmatic elements that guarantee a successful and timely recovery effort beginning at the time of declaration.

There’s a gap between how tests are designed and performed and the actual conditions your team will face during a crisis. Testing is much more controlled and predictable. Depending on how you’re conducting tests, there can be many differences between a test and an actual recovery.

Tests are typically pre-staged and scheduled for a time that is convenient for team members. In reality, disasters are unpredictable and almost always inconvenient. Tests may also be performed in isolated environments or involve only select team members.

The more your testing differs from the real-world conditions of a disaster, the less prepared you’ll be for an actual DR event.

Key questions to test the efficacy of your DR plan

There’s a possibility that your DR testing might not be as effective as you think. To gauge the efficacy of your testing, ask yourself the following questions:

  • Have you identified the unique challenges associated with an actual DR event versus those associated with DR testing? For example, if your test has been on the books for months, and your organization has been preparing for it, it wouldn’t be shocking for everything to run smoothly. However, actual events never follow a schedule. They require employees to drop what they’re doing, remember what they’ve been taught, and use their muscle memory to respond in real time at a moment’s notice.
  • Are your DR tests designed to simulate and prepare you for those unique challenges? Are you training like it’s the real thing or simply a practice run? If you’re only testing your DR plan because that’s “what you’re supposed to do,” then you’re doing nothing more than checking a box. If you’re only testing some of your teams as opposed to the whole organization or performing an isolated test instead of a full-scope effort, then you’re treating this like a practice rather than a game. This helps no one.
  • Are your DR tests increasing in scope and value over time? If you’re like most organizations, you’re continually adding new applications, removing redundancies, and migrating workloads to and from the cloud—all of which requires you to reevaluate and update your DR plan. You also need to consider interdependencies. Every application you add or subtract influences other applications. If you haven’t been updating your DR plan each time you make changes to your environment, then it won’t matter how often you test.
  • Will your DR program be effective recovering data in the aftermath of a cyberattack that encrypts or destroys data? Data recovery is a completely different recovery case than most DR plans account for and requires a different approach. Here are four ways data recovery differs from DR:
    • The triggering event: DR plans focus on recovering infrastructure, applications, and network services. These are all issues resulting from problems with your physical data center. Data recovery, however, stems from a cyberattack often with different impacts.
    • Where you recover: With DR, you fail over to a recovery environment. With data recovery, you can recover data at any location, including the original production environment, an isolated DR site, or both.
    • Which data you recover: DR plans typically rely on the most recent copy of data. With data recovery, you need to look for the available “clean” data for the recovery process, since the most recent might be compromised.
    • RTO/RPO: In DR, regular testing should enable you to meet your recovery time objectives (RTOs) and recovery point objectives (RPOs). In data recovery, you’ll have to quantify your possible RTOs and RPOs based on your situation.
  • How are you measuring the success of your DR test? Running a DR test is not enough. You need to have an effective method for distinguishing success from failure and measuring progress. For instance, do you have a trend report that outlines improvement in RTOs and RPOs? If you don’t have an efficient means of analyzing the results from a test, then you’ll consistently be missing a key piece of the puzzle.

If you can’t answer these questions, or if your response to any of them is no, you may be missing crucial elements of an effective DR testing effort.

Guidelines for successful DR testing

How, then, can you ensure your DR testing is not only consistent, but effective? There are a few principles to keep in mind that will help you be more successful.

  1. Don’t let lapses in testing become permanent. Testing lapses happen for many reasons. You might be working through other IT changes or challenges when testing comes due and, in those situations, it may make sense to defer a test for a month or two. That’s fine, as long as you get your testing program back on schedule. Consistency over time is what counts. If you’ve been testing effectively and haven’t made major changes to production, delaying a test won’t make or break your effort.
  2. Make sure your recovery center factors in your post-pandemic working conditions. With many companies allowing employees to continue a hybrid or fully remote work schedule following the pandemic’s end, you may have to adjust your recovery center if you haven’t already. Organizations have been able to execute DR plans remotely for a while now, but make sure your team has viable access to the recovery center if working situations have changed. If you still haven’t set up the configuration from home, make that adjustment now.
  3. Documented exceptions are OK, but every other issue equals failure. It’s only fair to set out certain documented exceptions to your full DR plan which do not make sense as part of a test. For example, establishing a link to your bank account in your recovery system to process payroll might be part of your DR plan. But during a test, you don’t actually want the bank to send an extra paycheck to employees. Document that exception and take the test as far as you can. Create that file and analyze whether it would match what you would send to the bank. On the other hand, if you’re in the middle of a test and realize you’re missing an essential file, you can’t go back to production, get the file, and continue the test. Since you wouldn’t be able to do that in an actual disaster, bringing something forward from production should be an automatic fail.
  4. Don’t forget to practice data recovery. Just like with DR, you need a team running through various scenarios where your data is compromised. Just as you tier applications for DR, you need to know your vital data assets, have a recovery architecture and procedures in place to safeguard them, and test often so you can act swiftly in the aftermath of a cyberattack to assess the situation and avoid data loss.

How often should you test your DR plan?

The honest answer is that it depends. There are two important factors to consider when determining the best testing cadence for your organization: how much downtime your business can afford and whether you’ve made major changes to your environment recently.  

Your recovery requirements will often influence your testing cadence. The shorter your RTO is, the more frequent your testing should be. For example:

  • One week recovery = one test per year
  • 48-hour recovery = two tests per year
  • 24-hour recovery = one test per quarter

In addition to your regular testing schedule, you should also perform additional tests after making major changes to your environment, or to internal or external recovery requirements. For example, if you typically test in March and September, but you make a change to your processing capabilities at the end of June, you should consider adding a test before September to make sure those changes are reflected in your DR plan. That way, if you experience a disruption between June and September, you’ll be certain the changes you made won’t derail your recovery.

Many organizations offer automated testing solutions that can help support these needs.

Changing how you test your DR plan

No matter how many times you test your DR plan, you won’t be ready for an actual disaster if you’re cutting corners.

Your DR plans must account for changes in your production environment, workflows, application interdependencies, and more. You must also prepare for unplanned scenarios, like the unavailability of some of your workforce or issues with your third-party partners (e.g., you can’t get ahold of a critical piece of equipment).

It turns out that practice alone does not make perfect. Practice only works if you’re practicing the right way. By incorporating these elements, asking the right questions, and treating your DR tests like they’re a real event, you’ll be more prepared to respond when a disaster strikes.


Girish Dadge

Girish Dadge has more than 15 years of experience unravelling data backup, restore, and recovery challenges, as well as architecting and implementing IT infrastructure and advanced recovery solutions across several industries. He currently serves as senior director of product management at Sungard Availability Services (Sungard AS).

Disk Backup Targets Get Modern Makeover
Every organization uses disk as a backup target. That is a given in organizations of all sizes. However, using a...
Disaster Recovery Investments Grow Revenue, Not Just Cut Costs
Today’s organizations are navigating unique business challenges amidst the increased cost and frequency of data breaches. Security incidents are overwhelmingly...
5 Tips for Organizations to Effectively Secure Their APIs
In today's increasingly interconnected and automated world, network cybersecurity has become more complex than ever before. The proliferation of application...
Fortifying Global Communications Security with Phone Number Intelligence Data
In 2021 alone, U.S. mobile users sent around 2 trillion SMS and MMS messages. That’s already an astronomical figure, but...