Myth Busting Disaster Recovery: Fact vs. Fiction

May 16, 2013 by Diana Nolting

Mythbusting Disaster Recovery Icon

How much do you know cloud-based disaster recovery? 

Recovery-as-a-Service, commonly referred to as RaaS, enables organizations to recover critical IT resources with increased efficiencies and complete effectiveness when an adverse situation strikes.  Cloud-based RaaS is nothing like traditional disaster recovery (DR) solutions of the past. Cloud-based RaaS users are able to install one piece of software (not an agent) which includes a control VM as well as an appliance on all participating VMware hosts. This increases self-service, testing and reliability of complete application protection. 

Even with all the changes in technology that have happened lately, there are still a lot of myths circulating that may have you confused about disaster recovery. Test your knowledge of what is fact and what is fiction with this short quiz, below. 


Myth #1 – One DR solution will cover your entire infrastructure: FICTION

It can be easy to believe one DR solution or product will protect your entire internal infrastructure; however one solution that protects all of your apps and workloads may not be the most trusted, secure, or cost-effective choice.

Bluelock Director of Product Solutions Ben Miller explains, “You may have some workloads that can withstand a week or more of downtime. Other applications may need to be up in minutes of a declared incident. The cost and technology to address each of those needs will vary and the solution for each should vary, too.

If your workload is already hosted in the cloud, it may require its own disaster recovery plan if your cloud provider has its own declaration. You’ll want to be able to failover to a second site by leveraging in-cloud RaaS or even by failing back to your own datacenter, if that's an option.

Myth #2 – Most disasters are not natural: FACT

You can plan for the tornado, the hurricane, or the power outage, but in reality the majority of disasters aren’t natural; they’re human. Disasters occur all the time that have nothing to do with metrological patterns.

The “fiber-seeking” backhoe, an incorrect code push that’s three versions old or an unexplained data issue are all examples of events that would activate your DR plan, but that Al Roker would have no way of warning you about.

Don’t assume your plan will only need to be activated if a meteor strikes, assume that your plan may only need to be activated in partial form. That’s where creating a plan that can recover only distinct applications comes in. It’s a more complicated plan than recovering the entire datacenter, but it’s more likely to be useful and needed.

Myth #3 – The DR plan is done when you failover: FICTION

Failing over is just part one of your recovery plan.  Your plan will also need to account for the failback, too, which can be one of the hardest parts of the process.

According to Miller, the secret to success with any disaster recovery isn’t in the technology at all, it’s about the strategy.

"You can use the best technology available with hypervisor-based replication and the latest features, but you could still end up breaking it,” Miller explains. “Success in recovering from a disaster is about a well-thought out design, test and recovery plan which includes the failback once the disaster is completed."

Look at the full plan for failback in order to make sure your plan is completely designed and well-thought-out.

One example of what you need to think about is how you’re sending your data back during the failback.  You may know you need 2TB of storage, but if you are sending it across an undersized network it may add time and money to the process.  If you undersize your DR plan needs it will be harder to manage and you can get trapped running in your temporary failover site longer than you would like. Having a good partner with strong advisory and services wrapped around your DR solution can be especially effective in this scenario.

Myth #4 – The only successful test is one that finds no errors: FICTION

Testing should occur early and often.  A common misconception is that you only need to test once successfully, and then you’re done testing. Though that was common with legacy technology that was bulky and difficult to test with, cloud-based RaaS allows and encourages lots of testing.

If you have a test that finds errors, that was a really successful test because it means you’ve established errors that you might have run into during a real failover.

Your application is likely to change a significant amount over the course of a calendar year. A static DR plan will likely be less successful in recovery compared to one that is tested at least biannually. Testing is not just about making sure a proper failover will happen, but it’s also about identifying and compensating for changes that have happened since your last test.

Testing with cloud-based RaaS is affordable and easy and some vendors, like Bluelock, even reimburse the resources used during pre-scheduled tests because they know the benefits of testing outweigh anything else you can do to prepare for a disaster.

Myth #5 – You can count on your staff to be there when a disaster hits. FICTION

One of the biggest incorrect assumptions that a company can make is that their staff will be there to help run the book in the event of a declaration.  That may be true if the declaration is the result of an internal error or minor disruption; however if the disaster that occurs is a larger, natural disaster that is causing the disruption, there’s a good chance your staff may not be any help to getting the systems up and running.

In the event of a hurricane, flood or other natural disaster your staff may not be able to get back to the datacenter, or they may be dealing with ensuring the safety of their own families.

By designing your DR plan to be able to involve outside help, you’re protecting your organization from the unpredictable. It might not be enough to have two of your staff trained for each failover position needed.

The runbook isn’t about what buttons you push, it’s also about who can help you push those buttons. The ability to make one phone call to a RaaS provider who is familiar with your DR plan and has tested the runbook with you could make all the difference in recovering.