Cloud disaster recovery can take many forms, whether it's using a public cloud, a hybrid cloud with an appliance on-premises backing up to a vendor's cloud, or even buying two appliances with one hosted by a vendor and one on-premises. Whatever the form, disaster recovery in the cloud is an emerging trend that allows users to ensure their data is protected in the unlikely and unfortunate event of a business interruption.
The selling point of using the public cloud is that it serves as a secondary site for companies that can't afford or don't want to maintain a colocation site. Those who do have a secondary site can set up a private cloud for disaster recovery (DR).
"The cloud is perfect for DR because it's off-site, and by the nature of moving your data to the cloud, you get archival and DR and backup all together," said Chandar Venkataraman, chief product officer with Druva, an endpoint backup software vendor that offers cloud backup services. "That's where I think everything is going to go eventually. Today, we still have organizations that are testing the waters on cloud. You have organizational cultures where they just want to do a private cloud deployment. I see two models today: private cloud and pure cloud for DR."
"The reality is, you can't have a conversation about IT modernization without talking about the cloud," said Jason Buffington, senior analyst with Enterprise Strategy Group. "We're going to continue to see that. That's only going to continue to grow. The trick is, there's still not a de facto way to accomplish that."
Venkataraman said that some of Druva's biggest customers, including glass manufacturer Saint-Gobain, use private clouds for DR.
"These guys, by organizational culture, are not ready to move to the [public] cloud," he said. "To them, DR means an off-site copy. They have invested in a private cloud architecture with a storage server in one location and set up replication in a different location."
Cloud backup vs. cloud DR
Emerging disaster recovery solutions go beyond backup and recovery. They allow users to back up virtual machines (VM) to a cloud, and in the event of a failure, the backup VM can be mounted directly as if it were the primary VM, while the primary is restored in the background.
Unlike traditional backup, cloud backup can turn into DR in certain scenarios.
Buffington referred to the two approaches as Backup as a Service (BaaS) and Disaster Recovery as a Service (DRaaS). "In a BaaS scenario, you are pulling files or data objects across and the normal outcome is to restore them back, but if the thing you are backing up is a VM in a different geography, why not just power it up?" he said. "By the way, the data movement technology that achieves more DRaaS, most of them are BaaS plumbing, basic data replication technology that's enhanced. Because of that, most DRaaS solutions allow you to do selective file restore as well, so you get BaaS as a side benefit."
Buffington said this is the roadmap to disaster recovery in the cloud. "There are different ways to take care of the tactical nature of backup, all of which are going to have an on-premises capability for fast restore and a cloud copy of some form. The question becomes, 'What does it take to make it a cloud disaster recovery solution?'"
Don't forget to test
As with any type of DR, cloud DR needs to be tested. Sandboxing and orchestration come into play when testing disaster recovery in the cloud.
"Rule No. 1 of a DR solution is you have to be able to test it. If you want to test a backup solution, you take a couple of files," Buffington said. "If you want to test a DR solution, you have to power up the VMs. The problem is, the live VMs are still doing their thing. If the live VMs are working, and I power up the test VMs, you could have an outage. So you need sandboxing, the ability to isolate what is in your DR environment so you can bring it up without impacting the production environment. Sandboxing allows you to power up in a vacuum without impacting the validity of anything else.
"Orchestration has two roles. You orchestrate dependencies between VMs. The file server might seem like a simple thing, but if you don't have a logon [on] the server, you need to bring up the Active Directory and another server. Sometimes there are up to three tiers of VMs. You have to bring them up in the right order or nothing works."
For example, you may need to bring up the most important VMs in two hours. Maybe you can wait 24 hours to bring up the next round of VMs, and 36 hours for the third round, and so on.
"There has to be intelligence and intent," Buffington said. "The worst thing to have is whoever screams the loudest gets their server first. You need a policy to define that."