Disaster Recovery sites are one of those things that consume a great deal of time, money, and resources. Then you sit back, and hope that you’ll never need the DR site you just so carefully built and invested in. Is there a better way?
There are of course ways to mitigate the costs of a DR site. One strategy is to leverage the equipment in your DR site to run dev/test. All that compute and storage ought to be doing something. Of course if you don’t have dev/test, that’s not an option. The other common strategy is to refresh your production data centre every few years, and move the old gear to the DR site along with the lowest levels of maintenance that make sense. Of course now your DR site is run on increasingly unreliable gear that is a generation behind in terms of performance. Plus you’re paying for data centre space, power, and cooling for something you’re hoping to never use. There must be a more economical way to tackle this problem.
There is.
One of the main advantages of the public cloud is that entire infrastructures can be spun up on demand. If you have the right orchestration tools, and a copy of your data in the right place, the bulk of your DR site can be created only when you need it. While the cost of tools to replicate and store data, as well as any orchestration tools to get you up and running are a given both on premise and in the cloud, the rest of the costs are not. Servers, networking, firewalls, load balancers… almost anything you can think of, can be ready to go in minutes. Unless a disaster actually happens, you pay nothing for all those resources.
Let’s start with the copy of your data. You will need one for disaster recovery purposes anyway, so locating it somewhere it can be used by servers in the cloud makes sense. If you want to keep your data “out of the cloud”, this can still be accomplished. By locating your backup target such as a tape library or backup appliance in a co-location site with high speed access to an Azure or AWS site next door, you still have on premise control of your data, but in a data centre a fraction of the cost of a full DR site. When a disaster happens, orchestration tools can spin up a compute environment and access your data directly.
The other option of course is to simply use the public cloud as a replication target. Options abound. The public clouds all have varying tiers of storage at different performance and price points. You can choose the lowest possible tier to keep costs down, and then depend on orchestration tools to promote that data to production class storage when needed (at the expense of a longer RTO of course). If you have a very tight RTO, you can locate your data on production class disk in the cloud. The overall cost will still be much less than building and maintaining an entire data centre.
Other choices are also possible. For those relying on de-duplication appliances on premise, these are frequently available as virtual appliances in the cloud, and can serve as an alternative backup target, or as a replication target for your on premise device.
The permutation and combinations are nearly endless, but the ROI case is stellar. That said, DR is never simple. Careful planning and testing is required to ensure that your plan actually works. This is where DR in the cloud delivers yet another major benefit. Non disruptive fail over testing is easily accomplished. With tests running for only a few hours, the cost is minimal. The benefit of this is that you can now test your DR plan, not only for less money, but with increased frequency.
In closing, there is one last benefit to building your DR site in the cloud. If at some point in the future, management makes the decision to move to the cloud, not only will you already be familiar with all the cloud constructs and how they work, but your migration is as instant as you would like it to be. You’re already there.
by David Hoffer and David White
*****
PS – If you’re looking for more information on how this approach might work for you, please feel free to hit the contact button, or attend our January 22nd Lunch and Learn on these and other cloud topics:
