5 Things To Consider When Building Your Disaster Recovery Plan

For anyone tasked with developing an IT disaster recovery (DR) plan, the alphabet soup of DR options talked about today by service providers, software vendors, analysts and pundits can be truly bewildering. Against this backdrop, analysts like Gartner predict dramatic growth in both the consumption and hype of “cloudwashed” DR services. For example, John Morency of Gartner claims, ”RaaS has been hailed as a ‘killer’ cloud app for disaster recovery, but the reality is that there has been much hype and some truth.”
I agree.
With the lack of standardization, it’s increasingly complex to map DR business requirements to business processes, service requirements and technology. How do you make sense of it all?
Start with the basics – protect your business by protecting critical IT operations and utilizing new technologies only where they make sense. Here are some things to think about as you consider DR in the context of modern, “cloudy” IT.
There is no such thing as DR to the Cloud (even though Rackspace has a DR to the Cloud solution).
There’s been a lot of buzz around utilizing cloud technology to improve the cost effectiveness of disaster recovery solutions. Vendors, analysts and others use terms like DRaaS, RaaS, DR-to-the-Cloud, etc. to describe various solutions. I’m talking about using cloud as a DR target for traditional environments, not cloud-to-cloud DR (that’s a whole other discussion). There’s one simple question underlying all this: If, when there is a disaster, these various protected workloads can run in the cloud, WHY AREN’T they there already? If security, governance and compliance don’t restrict those applications from running in a cloud during a DR event, they should be considered for running in the cloud today. Rackspace has a number of solutions for DR, including a “DR to the Cloud” for VMware environments.
YOU own your DR plan. Period.
Various software and services provide service level agreements for recovery time and recovery point objectives, but that doesn’t mean that if you consume those products, you have DR. For example, what exactly does the word recovery mean? Does it mean that a virtual machine is powered up or that your customers can successfully access your customer support portal? The point is, only your IT department can oversee that end customer (or employee in the case of internal systems) processes will be protected in the case of disaster. You can find help with BIAs, BCDR planning, hosting, etc. that provide key parts of a DR solution, but at the end of the day the ultimate responsibility for DR lies with the IT department.
Everyone wants DR, but no one wants to pay for it.
I’ve had lots of conversations with prospects and customers asking for really aggressive DR SLAs. Once they hear about how much it’s going to cost, the initial requirements change pretty quickly. The reality is that as objectives get more aggressive, the cost of DR infrastructure, software and labor begins to approach the cost of production. Careful use of techniques like using test/dev environments for DR, global load balancing of active/inactive workloads and less aggressive recovery time objectives can drive the cost of DR down to where it should be (about 25 percent of your production environments’ cost). Caution: Be skeptical of any solutions that promise both low cost and minimum downtime.
Service provider’s SLA penalties never match the true cost of downtime.
Ok, let’s be honest – unless you’re running an ecommerce site and you can measure the cost of downtime, you probably don’t know the true cost of downtime. Maybe you hired an expensive consultant and they told you the cost, but that’s based on an analysis with outputs highly sensitive to the inputs (and those inputs are highly subjective). This doesn’t mean that service provider SLA penalties don’t matter. Actually, strike that – service provider penalties don’t matter. A month of services or some other limited penalty in the event of missing a DR SLA won’t compensate for the unexpected downtime. If it did, then why are you paying for that stringent SLA in the first place? The point here is that only a well thought out and tested DR strategy will protect your business.
You don’t have DR if you don’t regularly test.
A DR solution is not “fire and forget.” To insure that your DR solution works, it’s recommended that you test at the user level at least quarterly. DR testing is also a significant part of the overall cost of DR and should be considered when building your business case. My advice if you implement a DR solution and don’t test it: Keep your resume up to date; you’ll need it in the event of a “disaster.”
There are many other things to consider when crafting your DR strategy – what keeps you up at night? Comment below and let us know.