6 DR Testing Best Practices for Guaranteed Recovery

IT evangelists consider a disaster recovery (DR) plan integral to business success. Yet, 75% of small businesses have no disaster recovery plan objective in place. But here’s the kicker: the rest 25% aren’t doing exactly great either. 

Often, businesses with a DR plan face the same consequence as businesses without a DR plan. At that point, IT pros question the very idea of having a DR plan in the first place. Instead, the question they should be asking is “what we can do to ensure the DR plan always works in exactly the manner we want?” 

The short answer is disaster recovery testing.  

Setting up a good DR testing process is crucial regardless of the size or nature of your business. Below, we share six actionable disaster recovery testing best practices to help set up successful disaster recovery.

1. Ask Questions 

The right DR testing approach varies for every business that is why you need to define the right DR testing approach for your business. Otherwise, you might end up randomly testing everything in the production environment, resulting in data corruption and loss.  

Define the scope of your DR testing by asking yourself critical strategic questions such as: 

Are you going to test the production environment using a cloud-based environment?  

How does friction make the IT team interact with each other?  

How good is the communication between departments?  

Your responses will help identify the criticality of each application and establish priority in terms of testing.   

2. Isolate DR Environment 

When testing, select a part of the DR environment, preferably away from the production environment. Vet the isolated DR environment at least a week before you start the actual testing.  

This practice ensures testing will not cause disruptions to other tasks running in the production environment. It’s a neat way to identify issues without hurting business continuity.   

The easiest way to isolate your DR environment and prepare it for testing is to create a secondary site with replicated servers and data to match the production site. You can also move the test site to a public cloud like Azure or AWS while your production site runs as usual. 

3. Identify Disaster Level 

There are different disasters with unique impact scales. For instance, VSS errors – tiny errors that don’t possess any major threat on their own – are one of the prime reasons for backup failures.   

You need different levels of response for different levels of disaster. This allows you to allocate resources to deal with small and big issues in the most efficient way.   

That said, the number of responses will add more complexity to the DR plan. It will play a factor in determining the most appropriate testing methodology. 

Below are some popular testing methods, but keep in mind, whichever method you choose, it should eventually cover all aspects of the DR plan.  

Walk-through. The DR team goes through each step of the plan verbally to identify weaknesses or gaps.   

Table-top/Simulation. Role-play through certain scenarios and carry out actual physical testing of alternate sites and equipment, and coordinate with vendors and others.   

Parallel. Recovery systems are set up and tested to see if they can perform actual business transactions to support key processes.   

Sandbox. Third-party companies offer disaster recovery as service (DRaaS) solutions that “sandbox” or partition virtual machines for testing without affecting production servers.   

Full interruption. Actual production data and equipment are used to test your DR plan. Be very careful when using this method because it has the potential to disrupt business operations and can be time-consuming. However, it can also be extremely worthwhile by demonstrating any gaps in your plan.   

4. Document Everything 

DR testing is no good if you don’t document it.   

Record observations that include what worked, what didn’t, timestamps on set completions and even impromptu tweaks to the testing process. This document will become the holy grail on which you will improve the efficacy of your recovery process.  

Here’s a checklist of things to be observed while testing:  

• Issues encountered during testing  
• Downtime duration for critical systems in case they don’t work as planned  
• Start to end timeframe of each DR process   
• Recovery objectives 

5. Practice Inclusivity 

Most IT departments are quick to send testing observations to senior management in the hopes of getting quick budget approvals. But don’t stop there. The DR testing findings should be shared with the other DR team members as well.   

Multiple copies should be available to keep the team abreast of any changes that could affect the DR plan. These reports help in the smooth onboarding of new DR team members as they can get up to speed with the current testing framework.  

Once the document has been approved by senior management, maintain both hard and soft copies. The hard copies must be placed in a physically accessible area, while a soft copy should be on the cloud. A DR testing document should be easily changeable with every iteration and it must reflect in all places for all stakeholders. 

6. Leverage BCDR Technology 

To execute an actionable DR plan, consider business continuity and disaster recovery (BCDR) technology. While businesses can use in-house technology to perform DR testing, the do-it-yourself attitude has led to a host of issues such as missing out on essential resources to other IT projects, inconsistent DR testing, expensive overheads maintaining secondary DR testing sites and lack of budget approvals. 

However, IT departments that partner with robust BCDR technology efficiently implement DR testing while keeping low total cost of ownership (TCO).  

For instance, Unitrends Unified BCDR solution delivers automated recovery testing, both onsite and offsite, with the ability to set recovery objectives and SLAs ahead of time — all compiled in neat reporting.   

Your DR testing is only good as your business continuity plan (BCP). Learn more about BCP, here.