The Best Way to Test Your Disaster Recovery Plan for Quality Assurance

A disaster recovery plan is probably the most ambitious, hardest, all-encompassing task an IT department will take on. If you’ve written a disaster recovery plan, take a moment and pat yourself on the back. Congratulations!

Now, once you’ve rested for a moment, it’s time to get back to work. A disaster recovery plan is only half of a will-actually-work-in-a-disaster, you-know-you’ve-got-yourself-covered fool proof plan.

That’s right: we’re talking about testing.

No matter how carefully, meticulously and patiently a disaster recovery plan has been constructed, there will be holes. Say it with me. Your business is a complex series of intricate independently moving parts and as such, your disaster recovery and backup plan also need to be, but that’s hard to do when you’re working in the hypothetical. You might think that your disaster recovery plan is bulletproof but you’ll never really know until it’s put to the test.

A hypothetical disaster recovery plan offers nothing if it doesn’t work when a disaster strikes. Testing a disaster recovery plan for quality assurance is the only way to ensure that your plan is ready for a real-world situation.

Disaster recovery plan testing: go from static to active.

When a disaster recovery plan is first developed, it is in stasis. The plan has been created. The hardware is ready. The software is up to date.

But then something changes.

Maybe something gets moved to another storage system to improve performance, but no one let’s the DR team know so the DR plan isn’t update. Uh oh. Suddenly, there’s a hole in your plan, but it goes unnoticed. That is, until disaster strikes.

Or until you test.

Disaster recovery plans should be constantly evolving.

Changes happen lightening fast in the average workplace. Most of the time, no one will even think about the impact it could have on the disaster recovery plan, and with testing disaster recovery plans so expensive and unwieldy, it could be a year before it’s found. And when everything is virtualised, digitised, and out in the cloud, it’s easier than ever to push configuration drift further along.

This situation where these little holes crop up and fall through the cracks of a static disaster recovery plan is called configuration drift. Enterprise Strategy Group says that 6 out of 10 recovery operations fail due to configuration drift.

Test early and often.

Aim for at least an annual test, but quarterly is even better. During these situations, it should be an all hands on deck situation where everyone is ready to jump into disaster mode.
This is the perfect moment to train your staff for how to handle a disaster. Practice makes perfect, after all. Creating a disaster recovery plan and then filing it away in a drawer will help no one if one of your servers goes down and no one is prepared for it. Let your staff learn now and not during an actual disaster.

To reduce the strain on the organisation, schedule tests to happen during anticipated slow seasons. Holidays and three-day weekends are perfect examples of great times to create a little “planned” disaster. Having said that, you should also test your plan during a normal business day, to anticipate any consequence that may arise in real conditions.

It’s all about preparation.

Building a complex, evolving disaster recovery plan can feel a little like nailing Jell-O to a tree. It’s hard to pin down (pun intended).

And then testing is a nightmare for business continuity. The idea of causing a disaster is so counter-intuitive.

An ideal disaster recovery plan is simple and effective and Macquarie Cloud Services has the answer.

We offer both disaster recovery and back up as a service solutions.

With our virtualised disaster solution powered by Zerto, you no longer need to maintain and refresh expensive secondary site infrastructure or manage complicated network failover processes.

If something happens to your primary site, you will be ready to save the day with a single click migration of workloads.

Best of all is that it’s as simple to test as it is to implement. You can test without affecting business operations or production applications. Now you can take testing from yearly to weekly and mitigate any risks from configuration drift.

Disaster recovery should never be a one-and-done task. It’s a constantly evolving process. If you’re interested in learning more about building the perfect disaster recovery plan, please download our free Disaster Recovery Plan Template.