Build your DRaaS

Disaster Recovery as a Service (DRaaS) is getting a lot of attention lately. The thought of outsourcing DR is appealing and in some cases, may be a less expensive option than an organization establishing and maintaining its own DR infrastructure. Backup, and especially recovery is still seen as a complex process by many organizations and is another reason why the thought of outsourcing the entire process is so appealing. DRaaS, though, is a capability that is not the unique domain of cloud service providers (CSP). Like many processes offered by CSPs, some organizations may find that they can build an internal DRaaS solution, retaining control of the environment and the performance guarantees.

What is DRaaS?

DRaaS is the re-instantiation of an organization’s applications as virtual machines in a remote facility, typically thought of as a cloud managed by a provider. There is some disagreement over how an organization’s data should be sent to the cloud provider. Cloud backup service providers have laid claim to providing DRaaS but since this data is stored in a backup format often on non-production class storage the recovery point and time objectives of these services is not typically in keeping with “instant” availability.

Tighter RPO/RTO requires that DRaaS replicates an organization’s data to their facility via an internet connection. Like a cloud backup provider, a DRaaS provider can help an organization recover specific data sets, but unlike a cloud backup provider, they can also instantiate entire servers as virtual machines in their facility with minimal data loss and downtime since the data is stored in a native format and often on production class storage. Another key element of DRaaS is the need for the solution to provide orchestration so the recovered application can be literally available at the click of a button and not require additional manual steps.

The advantage of hosted DRaaS to the organization is a reduction in disaster recovery (DR) site costs. The subscriber no longer needs to pay for a facility and equip it with infrastructure while it is on standby waiting for a disaster. Additionally, with many cloud providers, you have people who have executed on DR plans many, many times over. Most IT professionals have not experienced an outage and are not well-versed in the execution of a DR plan.

Business Continuance DRaaS vs. BaaS

As discussed above not all DRaaS solutions are the same, there is a difference between business continuance providers and cloud backup providers that have added DRaaS functionality. Business continuance providers are replicating live data continuously and are storing it in its native state. Business continuance providers are also orchestrating the recovery of applications so that process can be started with a few clicks. This is critical as most applications are dependent on several virtual machines and still may require additional target related configuration to be performed prior to the application being available.

Backup providers typically store data in a backup format. For backup providers to deliver DRaaS functionality in their cloud often means the extraction of the application and its data from the backup format and then positioning it into a separate compute environment. Essentially the cloud backup provider is restoring their customer’s VMs from their backup cloud to their compute cloud. The process is especially manual and lengthy, requiring extended restoration times and additional methods to extract the data without causing machine identity conflicts.

Because a business continuance DRaaS solution stores data in its native state (not a backup format), it can deliver tighter Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO). It doesn’t need to reposition data. At the heart of a business continuance DRaaS solution is an orchestrated replication solution. An organization armed with this solution only needs to select the most appropriate DR target; a self-hosted remote site, a remote site operated by a managed service provider or a remote site operated by a public cloud provider.

Do-it-Yourself DRaaS or Provider DRaaS

DRaaS is an ideal solution for many businesses, especially those that lack a secondary site staffed with IT personnel. Depending on the size of an organization’s data, storing multiple copies of it in the cloud for a long period of time may be more expensive than storing that data on premises. Organizations that use cloud backup need to be particularly attentive to these costs. The organization needs to weigh the hard costs and more importantly the soft costs and determine which data protection method is right for them.

The exception is when the provider’s storage is used solely for DR. In this case the only data stored in the cloud is just the most recent copies (over a shorter timeline), not a long term archive. In fact the combination of an off-site DR and an on-site archive is very compelling and may be the best example of integrating the cloud with the traditional data center, also known as Hybrid Cloud. Business Continuance focused DraaS leverages the cloud for what it is best at, instant compute, and the data center for what it is more economical with, long-term storage.

Ensuring Performance in the Recovered State

Making sure data is in position, failing the application over to the cloud, then getting users connected are important steps in the DR process. The challenge is to deliver acceptable performance to those connected users. The cloud, if it is public, is a shared resource. In a regional disaster, many organizations may declare at the same time, which means a shared environment may not be able to keep up with the demands of hundreds of businesses running simultaneously.

Public providers are probably more immune to this than smaller managed service providers are but smaller providers don’t have as many workloads to contend with and should be more attentive to their individual customers. Both options have their advantages, IT planners just need to make sure they understand the performance expectations of their applications while running in the provider’s cloud.

Selecting The DRaaS Target

All organizations need DR and more than likely need to improve their RPO and RTOs. An orchestrated replication tool is key in meeting those objectives. An automated replication solution allows the organization to select the DRaaS target that best matches their capabilities and needs.

A self-hosted DRaaS solution overcomes some of the challenges of a provider hosted solution but introduces others. Many larger organizations already have a secondary site that either has a data center, or is suitable for temporary data center operations. Although purchased upfront, the cost of storage at the DR site is not a one-time purchase, it needs to be refreshed at approximately the same pace as the primary site. That said, the pace of refresh, thanks to flash based arrays is slowing down, and modern storage systems should meet the needs of an organization for five or more years.  Additionally, because the DR site only runs that organization’s applications, maintaining consistent performance is manageable.

Even without a suitable secondary site, an organization can leverage the public cloud and drive the DRaaS process itself. The result should be greater control and security. If the cloud is the desired DR location, the use of orchestrated replication software, instead of cloud backup software, allows the organization to keep only the most recent copy of data in the cloud plus a small amount of previous versions, resulting in lower cloud storage costs.

Do-It-Yourself DRaaS Architecture

A key ingredient for a do-it-yourself DRaaS is the orchestrated replication solution, which is different than array-based replication (ABR). Array-based replication can be simple to manage groups of data, but doesn’t have the insight into the types of data housed also doesn’t typically include orchestration. Another caveat to ARB can only replicate to another identical array. The same-to-same replication hardware requirement limits DR site flexibility and eliminates the Managed Service Provider (MSP) or public cloud option. Array based replication is still popular in data centers. This technique leverages the software built into arrays to send data as it changes to another array.

Instead of array-based replication, IT planners should look for a software-based replication solution that can replicate from any array to any array as well as provide orchestrated recoveries. It should also not be dependent on a particular hypervisor, which would limit hypervisor flexibility and cloud selection potential. The orchestrated replication software solution should be able to replicate from any hypervisor to any hypervisor and from any storage system to any storage system, including cloud hypervisors and cloud storage.

Using an any-to-any replication software solution allows the organization to be in control of the DR process, but not have to spend capital on facilities, servers and storage systems until it is needed. If the relationship with the cloud provider is to act as a DR site, then only the most recent copies of data need to be stored there.

The selection of the right software enables organizations of almost any size to create this do-it-yourself DRaaS solution. If the organization has a second data center viable location, data can be replicated to it through this software. At the secondary site, using tier 2 storage or an alternative hypervisor can keep costs down. An organization without a viable secondary site can leverage this software to replicate to a variety of cloud providers including large public clouds like Amazon and smaller CSPs.

An important capability of the replication software is to make sure that the virtual machines in one hypervisor can run in another. It should be able to deliver a seamless migration between hypervisors and cloud locations.

Orchestration is the Key

The achilles heel to any recovery effort is complexity. A disaster is no time to remember which order to recover each application component. An orchestrated recovery effort allows the complexity to be removed ahead of time. As mentioned several times the replication solution should provide an orchestrated recovery capability so that applications can be brought back online with a few mouse clicks.

Using DRaaS for More than Disaster

DR is a “hurry up and wait” project. It requires plenty of planning and testing, but once in place the plan is waiting for a disaster that may never actually occur. With any-to-any replication, the foundation of the DR plan can be used for a variety of data center projects.

Better Testing

The most obvious use case is to use DRaaS solution as a DR test “site”. The number one reason that actual DR attempt fails is due to lack of familiarity with the process. DRaaS allows DR testing to move from a once or twice a year event to an ongoing task since the DR process is initiated in the cloud and can be quarantined from actual production.

Small Disaster Recovery

Most outages are not big disasters that take down the data center. Instead, they are the result of a single server failure, application corruption or storage system failure. With this replication software in place, critical applications could be replicated to a less expensive storage system locally and then again to the secondary DR site or the cloud. The secondary on-site storage system could be used to provide very tight RPOs and RTOs for disasters that are far more common, albeit smaller.

Better Test/Dev

The DRaaS foundation also enables better test/dev, especially if replication is occurring on-premises and in the cloud. Assigning snapshots of data in the secondary storage system or cloud environment to test/dev servers allows them to perform their testing on near production copies of data.

Recovery from Ransomware Attacks

Many organizations have one plan in terms of cyber threats, to keep them out but what happens if they get in? Organizations need to make sure they have plan A, plan B and plan C. Plan A of course is, keep out all threats. A DRaaS solution which includes journaling can enable an organization to essentially “undo” the attack and act as a solid plan B. Many organizations who have leveraged this approach have been able to recover from the attack without their end-users even knowing there was an issue. Plan C is recovering from a backup, which is a viable solution, just a complex and time-consuming approach. Most organizations will be down for a few days if recovering from backup is the only option.

Cloud Bursting

A DRaaS foundation that leverages the cloud also positions the organization to migrate an application to the cloud, or at least use the cloud when seasonal or unexpected demand strains on-premises resources. This capability, known as cloud bursting, allows data centers to be designed for the normal load instead of the worst-case load, reducing on-premises costs. The concern over cloud bursting is the time it takes to switch from on-premises to cloud instance. A DRaaS foundation allows migration and cloud bursting to occur more quickly since the data is already positioned in the cloud destination.


DRaaS is the future of disaster recovery, but leveraging cloud backup may be an expensive way to implement it. Cloud replication, because it is operating on the working set, keeps cloud storage costs contained. The cloud replication software also enables organizations with an IT ready secondary site to leverage that site and create their DRaaS. In either case, the organization is in control of when and how recovery happens. Do-it-yourself DRaaS also enables organizations to use the replication software to enable other cloud initiatives like bursting and test/dev.

Sponsored by Zerto

Eleven years ago George Crump founded Storage Switzerland with one simple goal; to educate IT professionals about all aspects of data center storage. He is the primary contributor to Storage Switzerland and is a heavily sought after public speaker. With over 25 years of experience designing storage solutions for data centers across the US, he has seen the birth of such technologies as RAID, NAS and SAN, Virtualization, Cloud and Enterprise Flash. Prior to founding Storage Switzerland he was CTO at one of the nation's largest storage integrators where he was in charge of technology testing, integration and product selection.

Tagged with: , , , , , , , , , , ,
Posted in Article

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 21,805 other followers

Blog Stats
%d bloggers like this: