As data protection vendors add cloud disaster recovery features to their offerings, they almost always include “push-button disaster recovery” as a feature, but they don’t explain what goes on behind the scenes after the button is pushed. Those behind the scenes activities can add hours to the recovery process, so while it only takes a second to push the recovery button it can take five to six hours for applications to be ready for users.
Behind the scenes of cloud disaster recovery
Every vendor does cloud disaster recovery a little bit differently but most on-premises backup solutions store backup data in their native backup format, not in a cloud native format. During recovery, there’s actually two actions required on that backup data. The first is recovering the backup data out of their proprietary backup format and storing it on high performance cloud storage.
The next step is a key requirement that most don’t realize is a necessity: transform the virtual machines into the format used by cloud provider’s infrastructure so that the machines can be booted by the cloud’s compute resources. Only then can the application be started in the cloud.
Most cloud providers have their own hypervisor that’s different than what’s in use on-premises, so this transformation process is almost always required. Based on our experience the transformation process can take four hours or more per virtual machine.
Orchestrating your recovery
During a disaster you are not recovering a single application but many applications and most applications are dependent on other services that typically run as VMs. In most cases, a single application needs four to six other VMs up and running before it can start. So, not only do you need to recover multiple applications, you have to recover them in the right order, all while the data center may be literally falling down around you.
One final consideration is failback. Once you go through the process of manually recovering VMs in the right order, transforming those VMs and getting them running in the cloud, how do you get back out of the cloud? Most solutions have no automated option to get you out of the cloud. The reason is simple. Since they don’t have a cloud-native version of their application, their solution got washed away with your data center.
How Druva does it better
Druva solves the VM translation problem by leveraging the native compute and storage resources of AWS. On-premises and cloud workloads are backed up to the Druva Cloud Platform for primary backup and recovery. Based on customer policy settings, VMs are then converted to AWS EBS snapshots that are kept-at-the-ready inside the customers’ AWS VPC for immediate spin-up of AWS EC2 instances at the time of failover. This eliminates hours of potential delays to get customers up and running quickly after disaster strikes.
Druva automates disaster recovery by enabling you to create a disaster recovery runbook, which makes sure that all the virtual machines, on which an application is dependent, are recovered and started prior to the application itself. The result is disaster recovery works like you expect it to. You push a button, a runbook automatically instantiates at-the-ready VMs in Amazon EC2, and your organization is up and running within minutes after even the worst disaster strikes. With disaster recovery safely secured in the cloud, you can manage recovery from anywhere.
Druva can automatically recover servers back into your data center when you are ready to return to your on-premises infrastructure, quickly and easily. Or recover to VMware Cloud (VMC) on AWS if you prefer, and Druva can continue to be your backup solution for VMC on AWS.
Druva’s disaster recovery as-a-service can save your business when disaster strikes. To learn more about, check out Cloud Native Disaster Recovery on AWS or disaster recovery solution and see what Druva can do for you.