What is a disaster recovery test?

 A disaster recovery test is important to business continuity. A DR test is process of running through each step in a disaster recovery (DR) plan, as outlined within an overarching business continuity plan. These steps, known as the disaster recovery drill, will activate, analyse and report on the effectiveness, speed and reliability of DR technologies such as failover, failback and backup. To find out what’s included in IT DR, click here.


Why disaster recovery testing is important

Studies continuously show that businesses collapse or suffer significant financial hardship following substantial data loss, whether through cyberattack or IT infrastructure failure. One study from PhoenixNAP suggests that of those companies without DR, 93% will be out of business in one year if they suffered a major data breach.

The forecast isn’t much better for businesses with DR plans, either. Troublingly, approximately one quarter of businesses have never tested their DR plans, despite the huge financial and operational risks associated with ineffective DR. This is even with 50% of average businesses lacking the budget to recover from a cyberattack, and experienced a downtime event in the past five years exceeding a full working day.

For those with confidence in their DR though, the picture is far more optimistic. 96% of companies with a trusted, tested backup and disaster recovery plan are able to survive ransomware attacks, for example. And as the famous Franklin quote goes, “failing to plan is planning to fail”. So, if you can’t guarantee that your plan will work as intended, it unfortunately has little worth.

This is precisely why testing disaster recovery plans and technology solutions is so important. No matter how advanced your software, meticulous your planning or well-briefed your people, it’s impossible to know if your DR is fit for purpose if it isn’t tested.

Businesses have become dependent on high availability, which means that an IT disaster can have catastrophic, lasting effects on operations, service and profitability. So, testing must go beyond checking that things “work”. You must test your DR solution from start to finish to determine that processes and technology also perform to the level required to maintain acceptable operations.

Recovery point objective (RPO) and recovery time objective (RTO) are two important measurements that need to be tested too. For more about DR metrics and key terms, check out our ultimate guide to IT DR here.


How often should disaster recovery be tested?

 A complete DR test is typically run once or twice a year, depending on the complexities of your plan and any change of circumstances in your business.  Although a full test can be understandably disruptive (after all, you’re essentially doing a dry-run of a plan designed to protect you from worst case scenarios), the process shouldn’t change that much in a 6 to 12-month period. However, stimulating a DR test on a regular basis can’t be done.

On a smaller level though it is wise to run “spot check” tests on IT systems, to check that essential technology is doing its job. For example, a test could be run within your live IT system using virtualisation or “DR as a Service” (DRaaS) could be used to run frequent reports on backup cycles, for example, so your time is taken up with arduous manual checks.


Reasons why businesses don’t test DR

According to one study, of businesses that do test their DR (and as we know, many do not), 34 percent do so least once per quarter. 29 percent test their plan just once a year and 14 percent test only every couple of years – these are concerning figures to us as an IT provider!

According to a SpiceWorks survey, reasons DR plans don’t get tested vary between: not enough time (61 percent), inadequate resources (53 percent), DR is not a priority (34 percent), DR process is too complex (11 percent), and testing being considered too expensive (8 percent).

First off, given the business continuity risks of being caught without a plan, DR testing should be high priority in any business (although we appreciate that IT DR will be lower down the list for industries such as manufacturing, logistics, petrochecmical and critical national infrastructure). And in terms of time, resource and complexity, a DRaaS solution will streamline and demystify.

The costs of recovering after an IT disaster will likely exceed that spent on prevention and recovery. However, modern solutions have many options – including pay as you go models and scalable packages – meaning that routes are available for those on a tighter budget.

disaster recovery terms

How do companies run a DR test?

 DRaaS will test whether the systems involved in DR are functioning to the business requirements. For example, it will force a data backup or restoration, and connect to a skeleton system on a failover server and run applications. DRaaS is primarily concerned with two types of DR testing steps:

Parallel test: Recovery systems are implemented and tested to see if they can perform actual business functions and processes. Primary systems still carry the full production workload, and parallel testing may be undertaken during hours of operation.

Cutover test: Recovery systems are implemented to assume the full production workload. Primary systems are disconnected and technology is tested. This may be undertaken overnight and part of the test is reconnecting to the primary system.

To supplement DRaaS functions, IT DR should also be periodically tested in the following ways:

  • Paper test: Responsible owners read and annotate IT DR plans
  • Walkthrough test: Groups walk through plans to identify issues and changes
  • Simulation test: Groups simulate a disaster to identify whether DR plans and tech are adequate


The first step to building a DR testing strategy is a consultancy session with a specialist. This service will assist you in determining testing schedules and metrics, testing types and much more. To arrange a session, speak to a Starcom consultant. 

by Stuart Buckley

Sales Director

An IT specialist for over 20 years, with a wealth of technical and commercial knowledge, experience and skill in managed services, cloud and hosted solutions.