Deploying Disaster Recovery Through a Cloud Service: 10 Best Practices

by Chris Preimesberger

With the influx of cloud storage and cloud backup options, it’s easy to settle for a solution that promises that data is safe in the cloud. This is especially true as people race to satisfy compliance requirements with “check the box DR.” However, just because the data is secure doesn’t mean it can be recovered quickly or that applications will be up and running in a reasonable time. True disaster recovery plans are about limiting or eliminating downtime so business continues to run when something goes wrong.

Just as some companies oversimplify and settle for backup alone, others overinvest in DR plans and end up with solutions that are expensive overkill. Teams should assess what capabilities are most important to them first. Is it fast recovery times, the ability to manage failover without third-party involvement, near real-time automated recovery, budget? Also, internal and external applications must be evaluated in terms of impact to internal operations, revenue streams, customer satisfaction and other business considerations.

While most teams focus on assessing infrastructure needs, understanding people and process requirements is critical. Who is accountable for triggering a failover? When should they trigger it? How will operations fail back once a disaster is over? Too many teams overlook these questions. Forrester Research recently reported: “When we asked decision-makers who had experienced a disaster to identify their top challenges, the top five challenges indicated that a lack of process maturity is to blame for most of the issues.”

Users must be able to easily access the data once it is recovered, particularly when an organization is geographically dispersed or has remote employees. If this step is skipped and disaster strikes, teams scramble to grant access and expose the data to more risk. IT should implement network options including MPLS, VPN, point-to-point and static IPs so that it can preconfigure user access and prepare for disaster recovery and testing.

The back-end hardware and software of a cloud must be able to run an application like the original production site. Evaluate a provider’s SLAs, uptime and performance guarantees, as well as capacity and scalability capabilities. When it comes down to it, IT should look for a DR site that very closely mirrors its own data center or primary cloud.

One common pitfall is bandwidth limitations that prevent replication between sites, either at the primary data center or on the provider’s end. Pay attention to latency and throughput between sites and stability of the bandwidth. Speed is critical to achieving recovery point objectives, and stability is key to ensuring teams don’t have to re-replicate due to breaks in the connection.

Teams tend to lump all of their applications into the same recovery plan, which results in wasted resources or lost data. Applications should be treated differently. IT should prioritize the order in which applications are recovered, how frequently each application is replicated and the retention of the recovery points. By doing this, it can ensure applications are consistently recovered in the most efficient way possible.

Industry standards and compliance requirements put a great deal of pressure on IT resources. Teams must have a thorough understanding of what information they are required to store, how long they must store it, where it must be stored and who can access it. All of these considerations play a key role in developing a DR plan and choosing a DRaaS provider. For example, not all providers allow you to choose where your data will reside, or they charge a premium for that capability.

Testing should be a priority in any disaster recovery plan, as it frequently uncovers flaws that can be corrected before a real disaster strikes. Traditionally, IT teams failed to test regularly because it was complex, expensive and disrupted service. With cloud-based disaster recovery, teams can take advantage of scripted tests, on-demand resources and technology that allows them to test any time without disrupting applications.

IT is increasingly looking to DRaaS providers to give them recovery capabilities that just a few years ago were only available to companies with large IT footprints. For many IT teams, a DRaaS implementation is the first experiment with cloud, and the process of selecting a vendor and executing a DR plan is extensive. That due diligence is valuable when it comes time to evaluate the cloud for broader IT initiatives. Teams should consider whether a DRaaS provider can support capacity requirements beyond DR should the need arise due to growth or business agility requirements.