The cloud reduces an organization’s disaster recovery (DR) costs while at the same time upgrading its quality. Cloud DR has a mathematical advantage over internal DR. The organization doesn’t have to invest in a DR site nor does it need to equip that DR site with servers, networking, storage and personnel. To benefit from the mathematical advantage the organization has to execute an actual cloud recovery. There are three concerns that IT needs to lay to rest before it can have confidence in the cloud recovery effort.
Internal disaster recovery means the organization owns all the variables. It can insure that all the hypervisors are the same, that servers are able and powerful enough to run the workloads and that the data is restorable quickly enough to meet recovery time and point objectives. In a cloud recovery situation the provider now owns most of those variables. The organization needs to understand how recovery occurs in the cloud just as it does if it owned the DR site.
Concern 1: Understanding the Recovery Environment
The first area of concern is the recovery environment. If for example the organization uses VMware as their hypervisor but the cloud provider uses a Linux based hypervisor, which requires some sort of transformation, both when starting the cloud recovery and when failing back to the data center after the disaster passes. Transformation of VMs takes time and will add to recovery times. A different hypervisor also means that during the disaster, the organization’s IT teams needs to manage the environment with a different management tool other than vCenter.
Concern 2: Performance of the Provider’s Environment
The second area of concern is the performance capabilities of the provider’s environment. IT needs to make sure that the provider has enough compute resources and can deliver production storage performance. If the cloud provider needs to transfer data from backup storage to higher performance storage, the transfer time will impact recovery times. If the provider plans on leveraging backup storage for production storage, the organization needs to make sure the performance of that storage will meet the application’s needs.
Concern 3: Failing Back
The final area of concern is failing back to the primary data center. Depending on the state of the data center, the backup techniques mentioned in our blog “Three Steps to Moving Legacy Backups to the Cloud” may not help. If the disaster completely destroys the data center and the backup software needs to recover to a new storage system, there is nothing for a technique like deduplication to leverage during recovery. Even if data survives the disaster, not all backup applications can perform a data comparison on recovery, instead restoring all data blindly.
Transferring information back may take a long time. While that data is trickling back across the internet, the organization is paying to run their application in the provider’s cloud.
The organization needs to prepare for a complete recovery of data, and just like when seeding the cloud for backup, organizations should look for providers that have the ability to ship baseline data to the customer, so that only changes occurring in the cloud, during shipment of the foundational set, needs transferring across the internet.
These are multiple ways for a cloud provider to address these concerns and there is no perfect answer. An important part of creating a “great” disaster recovery plan is getting these concerns on the table and addressing them in advance.
To learn more about moving your disaster recovery plan from “good” to “great” watch our on demand webinar “How to Create a Great Disaster Recovery Plan“.