If your company hasn’t yet encountered an IT disaster, it’s probably only a matter of time before it does. Whether it’s a faulty network card, natural disaster or cyber-attack, companies of all sizes need to formulate disaster recovery plans (DRP) that will ensure business continuity when disaster strikes.
The traditional approach to disaster recovery (DR), particularly for large enterprises, was to build and maintain a separate datacenter out of harm’s way from the primary site. Such a configuration necessitates expensive high-speed WAN connections between the datacenters to reduce the distance-induced latency to a moderate level.
Due to the exorbitant cost of maintaining a fully operable secondary datacenter just for DR, this approach was a non-starter for companies with smaller IT budgets.
Cloud-based DR has emerged to address this issue. Rather than setting up a second physical DR site, enterprises can use the cloud as their secondary datacenter. This cost-effective approach leverages cloud economics to make DR attainable for smaller companies as well.
Why DR in the Cloud?
Gartner predicts that by 2025, 80% of enterprises will shut down their traditional data centers as IT operations and workloads migrate to the public cloud. This is a major undertaking, and many enterprises are looking for ways to reduce the risk and complexity of their cloud transformation initiatives.
In this context, DR can serve as a bridge for companies transitioning from their on-premise datacenter to the cloud by using the cloud as their secondary data center. Moreover, companies that have already transitioned their primary datacenter to the cloud are setting up DR sites in a second availability zone or at a second cloud provider (multi-cloud) for enhanced business continuity.
So what makes the cloud such an attractive option for DR?
1. Less costs. The public cloud greatly reduces DR site costs since you pay only for the computing and storage resources you use. Application servers are shut down or run at minimal capacity during normal operations at a negligible cost. Unlike NAS storage where you also pay for unused capacity, storage capacity in the cloud is elastic (i.e., pay as you grow). In many cases there’s no additional cost since you need this capacity anyway for backup.
2. Less risk. Moving to the cloud can have major business implications, and many enterprises prefer a low-risk incremental strategy. Rather than moving your entire infrastructure to the cloud, moving DR to the cloud lowers risk and preserves the existing datacenter investment.
3. Better compliance. FINRA, HIPAA and other industry regulations stipulate DR compliance. For example, FINRA regulatory notice 13-25, issued after Hurricane Sandy ravaged the northeast coast of the United States in 2012, states that a secondary datacenter in close proximity to the primary site may not sufficiently protect a firm from the effects of a region-wide event.
4. Lower entry barrier. The extreme cost of traditional DR approaches created a high barrier for entry, impeding many companies from entering highly regulated markets. By changing the economics, cloud-based DR enables smaller companies to join the game as well.
5. Faster response. Using the cloud also means that enterprises can respond more quickly to a disaster, sometimes in as little as minutes, minimizing the business disruption. Cloud orchestration and automation tools help automate the in-cloud recovery process from end to end. In comparison, traditional DR sites based on manual activation, data replication and migration of users can take days or weeks to setup, making it impossible to meet recovery SLAs.
Enterprises are re-evaluating their disaster recovery strategies as they continue to migrate their IT infrastructures to the cloud. Cloud-based DR enables enterprises to improve business continuity and enable compliance with industry regulations in a cost-effective manner.
In my next post we’ll talk about some best practices for deploying DR in the cloud, including how to implement zero-minute disaster recovery and how to overcome latency.