Many organizations realize the importance of implementing a Disaster Recovery (DR) solution, or are required to do so to comply with government regulations. Maintaining a separate on-premises site to serve as a DR target is labor intensive and requires significant investment to deploy and maintain, especially when considering that it is not utilized on a day-to-day basis. Disaster Recovery as-a-Service (DRaaS) running on an elastic public cloud with built-in automation reduces the amount of under-utilized hardware and maintenance tasks, simplifies the deployment in case of a DR event, and increases the reliability of the DR solution with non-disruptive testing.
On-premises DR solutions are often expensive and require extensive expertise to deploy, maintain and operate. Deploying an on-premises DR site means paying in full for DR real-estate, hardware, and software, but using them only when the main data center goes down. This makes it difficult for IT decision-makers to justify the high expenses of such initiatives. Even after a DR solution has been deployed, testing it is often labor intensive and disruptive. As a result, many organizations compromise on the level of protection their business-critical applications receive in the event of a disaster. To overcome these challenges, many organizations look to the public cloud. The goal of this guide is to help organizations understand the key factors they should take into account when considering public cloud as a solution for their DR needs.
LANDSCAPE OF DISASTER RECOVERY SOLUTIONS
1. Data backup only
These solutions replicate organizations’ data to a second on-premises site or to the cloud. However, they leave organizations exposed to long down-times during disasters since applications do not have infrastructure to run on. They also do not include simple DR testing, and require extensive manual work once infrastructure is acquired.
2. Automated DR to an on-premises site or to a co-location
Solutions of this kind reduce the amount of manual effort, but still require high capital investments in real-estate, hardware, and software that are not often used. Additionally, they are more difficult to scale.
3. Automated DR to data centers owned by DRaaS providers
These solutions provide most of the benefits of automated DR to an on-premises site, and have a better cost structure that reflects the infrequent use of the DR target. Customers of these solutions should assess the reliability of the DR infrastructure and the financial stability of the DRaaS provider.
4. Automated DR to a global mega-cloud
These solutions provide most of the benefits of automated DR to an on-premises site, and have a better cost structure that reflects the infrequent use of the DR target. Customers of these solutions benefit from reduced risk thanks to the reliable infrastructure, global availability, and financial stability of the mega-cloud provider. However, some of these solutions require replatforming of customers’ applications.
DISASTER RECOVERY AS-A-SERVICE (DRAAS) USE CASES
1. Entirely new DR
Meant for organizations that have only backups or do not have any DR plan in place.
2. Expand existing DR plans
Some organizations already have an on-premises DR solution, but they use it only to protect a few workloads. With DRaaS, these customers can protect the rest of their workloads to the cloud, while keeping their existing DR plans unchanged.
3. Replace existing DR
Some organizations have a mandate to reduce their on-premises footprint or “move to the cloud”. DRaaS is a natural solution to move the on-premises DR site to the cloud.
4. DR between different cloud regions
Even the largest public clouds have outages, making DR relevant to customers who are running apps in the cloud. Customers of DRaaS solutions can protect their applications between different cloud regions.
As organizations turn to public clouds for Disaster Recovery as-a-Service they should consider various factors of their DR strategy. A robust DRaaS offering should be able to provide the RTOs needed for business-critical applications. It should also offer orchestration and automation of the failover process, and non-disruptive testing. All this should ideally be done without the need to replatform applications, and run on top of a reliable public cloud.