BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Historically, disaster recovery (DR) offerings have run the gamut from ways to simply get data off-site, to replicating data sets to a second physical location or completely mirroring an infrastructure that runs in a failover mode. The thing that differentiated these products was recovery time, or how quickly an application could be back online. While all could be called "DR," these services varied widely in what they provided.
The faster a company needed its applications back up and running, the more complexity and cost they had to assume. And lower-end products were essentially limited to restoring data, not actually recovering applications. For many companies, the cost of a more sophisticated DR as a service offering was just too high.
Today, the cloud has greatly enhanced those options. If recovery time is the metric that determines how effective the DR as a service provider is, then good DR is now available for a lot more companies.
What is DR as a service?
The cloud has made "as a service" part of the IT lexicon, joining the list of options that IT managers can deploy. These offerings are essentially various combinations of compute and storage infrastructure and applications running in the cloud that cloud companies sell access to.
Server virtualization allows providers to package the entire IT environment into a cloud service, like Amazon has done with EC2, allowing companies to exist without ever owning a server. This capability of running virtual machines (VMs) in the cloud has enabled DR to join the list of "as a service" products, dramatically bringing down the cost of high-quality disaster recovery protection.
But rather than just providing a safe place to transfer a company's most critical data and (hopefully) get it back soon enough, DR as a service also provides a platform on which to actually run those applications in the cloud. This addresses the primary challenge of DR: recovery time. Here's how it works:
The company's critical VMs are replicated to a host in the cloud and kept current with regular updates. Then, when a failure occurs on the local host, a failover mechanism kicks in and points users to the VMs running in the DR as a service provider's cloud. Following the outage when local infrastructure has been restored, those VMs can be migrated back to the company's data center or resynchronized with the local host. This can be done over the Internet if the amount of data is relatively small, or can involve shipping a storage device.
Obviously, running these applications directly from the cloud subjects those users to more latency than when running locally, but the impact of this would depend on the application itself and how much actual data transfer it had to do.
Keeping a VM updated in the cloud can require a lot of bandwidth and restoring it locally after a server goes down can take hours (or more). And more importantly, in a pure cloud service, all this data movement must be handled by the application server. For these reasons a hybrid cloud model is especially effective for DR as a service.
Hybrid cloud DR as a service includes putting a server on-site that functions as the local replication target and local failover appliance. When an application fails, its corresponding VM can be started on the appliance by an administrator, giving users a recovery measured in minutes, depending on backup frequency, instead of hours. For events that don't take out the company's building, having the local failover host eliminates the latency issues that the pure cloud DR as a service product has.
On the back end, the hybrid appliance replicates VMs regularly to a cloud host, handling all the communication and data transfer and removing this load from the primary application servers. Also, many hybrid DR appliances also offer data reduction functionality to maximize bandwidth utilization.
Some hybrid DR as a service products can also provide protection for non-virtualized servers as well. They do this is by running a physical-to-virtual conversion of the local bare-metal server, creating a virtual recovery node that is kept updated like all the other VMs on the target appliance.
Of course, hybrid cloud DR as a service isn't perfect. Running an application from the cloud does involve latency that's simply not there on the primary production servers. And, depending on the product chosen, failing back from the cloud can be a complex process and involve some downtime. But the alternatives can involve more downtime, more complexity and certainly more cost.
DR as a service can provide a highly functional disaster recovery product that is also very cost-effective. The right hybrid recovery appliance can give a smaller organization "big company" DR, with near-real-time failover and a reasonable recovery window from the cloud. Hybrid cloud can also provide a high-availability infrastructure for multiple applications (on physical or virtual servers), offering protection against the much more common "disasters" in which a server fails, without the site going down.
DR as a service turns DR hopes into DR plans
Cloud DR services: Customers want DR as a service
DR as a service terms you need to know