Get started Bring yourself up to speed with our introductory content.

Virtualization makes DR in the cloud an attractive option, but caution is advised

Eric Slack details what you should know about your cloud provider's infrastructure before deploying DR in the cloud.

Disaster recovery (DR) is a dedicated process that's designed to bring critical applications back online after...

an unexpected outage. DR methods can range from simply carrying backup tapes or disk drives home in a backpack to maintaining those applications in a dedicated secondary data center. And, the "cloud" has become a popular alternative to this secondary data center. The big differentiators between DR options (assuming the backpack isn't appropriate) are how fast the DR system can provide recovery after a disaster and cost.

Cloud DR is a new option that leverages two pervasive technologies: server virtualization and cloud-based storage and compute services. When implemented "as-a-service," cloud DR is giving companies a cost-effective way to get relatively fast recovery. But there are risks. In this tip, we'll explore cloud DR, several related topics and identify what you should look out for.

Making cloud DR work

At the heart of a cloud-based DR solution is server virtualization, a technology that encapsulates an entire server instance in a few files. In the process it abstracts the operating systems and the applications they support from the underlying server hardware. This makes these applications more portable and facilitates their transfer to the DR site, whether that's at a separate company location or in the cloud.

By leveraging changed-block tracking and data reduction processes like deduplication and compression, these server images can be kept updated in the cloud efficiently. Also, virtualization technologies enable those VMs to be restarted or recovered "in place," in the location where they're backed up.

Recovery in place

This is a process by which backup VM images can be restarted directly from the devices they're stored on. In a local context, the VMs are usually stored on a backup system (typically a dedicated backup appliance) that's in the same data center as the primary application servers. In a cloud DR context, these VM files are stored on either dedicated or shared storage resources that are connected to virtual server hosts. This way, they're ready to be run when a disaster event occurs. Leveraging its portability, a specific VM can be moved to an available host within a pool of compute resources that's allocated to support potential recoveries.

DR as a Service

This abstraction and portability allows VMs to be restarted on any physical server hardware that's running the same virtual server OS, in the company's data center or in the cloud as well. These capabilities also enable DR to be sold as a service, an attractive option for companies that don't want to support a dedicated DR location. Many backup vendors have cloud storage capabilities and are now providing virtualization platforms on which to run VMs, giving their backup clients a DR solution that they pay for as an upgrade to their monthly backup service.

Another option is to use a vendor that runs a hosting or cloud-based storage and compute infrastructure business that's added a DR service to their line card. Typically focused on the larger end of the market, these offerings can range from turnkey solutions that the vendor installs on-site and manages to simply supplying infrastructure components that the company needs to essentially create their own cloud DR solution.

Reality check

Storing VM images ready to restart on a host in the cloud is an easy concept to understand, but there's quite a bit more to implementing a cloud-based DR solution that meets the expectations of the company. When considering cloud DR, companies need to understand the realities of running critical applications in the cloud, possibly for extended periods, in order to make the right decision about implementing this technology.

Getting users connected to these applications means firewalls, port monitoring, intrusion protection, security, etc. Running production applications in the cloud, for days, or weeks, requires more than just storage, but the compute resources to support the company's critical applications. It also requires the network resources to support hundreds or thousands of users that may hit those servers.

Cloud backup becomes cloud compute

As soon as a backed-up VM image is restarted, that cloud backup provider becomes a cloud compute provider, a conversion that should prompt several important questions. Do they have the infrastructure in place to handle the demand from all the company's applications? Can they support this same demand from many of their clients when a regional disaster brings down multiple companies' data centers? Do they offer service-level agreements to guarantee adequate performance? And what about uptime? Compute infrastructures need reliability and redundancy that goes beyond what's required of most backup systems.

Exit strategy

And what about the process for returning to normal? Applications running in the cloud can generate significant amounts of new data. After the disaster has passed there needs to be a transfer of that data back to the primary data center. Depending on how much data is involved and the bandwidth available, this may mean shipping a storage device from the cloud facility. There also needs to be a process for synchronizing primary servers with the DR copy, all without disrupting critical programs.

Thanks to server virtualization and cloud-based services, most companies can afford an effective DR solution. These DRaaS offerings are available from a range of suppliers, including existing cloud backup vendors and cloud infrastructure providers.

However, running critical applications in the cloud is quite different from providing a storage service, so the DRaaS provider's infrastructure must be up to the task. They need enough dedicated compute and networking resources available to cover a company's projected demands, for as long as they need to run in the cloud, and to cover multiple companies' demands in the event of a regional disaster. After the disaster has passed, there also needs to be a solid plan for getting application data out of the cloud and synchronized with servers in the primary data center, without disrupting production.

About the author:
Eric Slack is an analyst at Storage Switzerland, an IT analyst firm focused on storage and virtualization.

Next Steps

DR in the cloud best practices

How to use DRaaS for DR in the cloud

A closer look at cloud-based DR

This was last published in January 2015

Dig Deeper on Disaster recovery storage

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

"Do they have the infrastructure in place to handle the demand from all the company's applications? Can they support this same demand from many of their clients when a regional disaster brings down multiple companies' data centers? Do they offer service-level agreements to guarantee adequate performance? And what about uptime?
And what about the process for returning to normal?"

All good questions. We've already seen that some cloud companies have had unexpected outages just from thunderstorms, let alone hurricanes or earthquakes. There's also the sovereignty question, which isn't settled law yet.
Cancel

-ADS BY GOOGLE

SearchSolidStateStorage

SearchCloudStorage

SearchDataBackup

SearchStorage

Close