Essential Guide

Building a disaster recovery architecture with cloud and colocation

A comprehensive collection of articles, videos and more, hand-picked by our editors
Manage Learn to apply best practices and optimize your operations.

Disaster recovery as a service wipes out traditional DR plans

Disaster recovery planning and infrastructure builds vex IT managers. Cloud services offer lower costs and more flexibility, but not without risk.

Disaster recovery as a service means more deployment and testing flexibility for enterprises, but also more recovery...

uncertainty.

Disaster recovery (DR) causes plenty of headaches; DR systems are expensive, hard to configure, difficult to test and quickly outdated.

Disaster recovery as a service (DRaaS), a cloud-based method, costs less, is easier to deploy, provides the ability to test plans regularly and keeps pace with corporate changes.

The catch is that cloud-based disaster recovery options may be unavailable after a catastrophic disaster. This means stranded IT resources and data, paralyzing the business.

How to construct a DR plan

Data center staff members put a lot of time and effort into devising and testing DR scenarios in collaboration with business stakeholders.

First, outline potential disasters for the data center: Hazardous weather, power outages, vendors' systems going offline, employee sabotage or outsider attacks are all possibilities.

Identify which of its hundreds of applications the corporation needs online immediately. Audit the list and prioritize by importance to daily operations.

Next, source and install redundant data center infrastructure -- servers, software, network connections, storage -- to support the applications. Disaster recovery plans cannot escape cost considerations; an offsite data center is expensive.

Typically, the DR plan calls for duplicating each application's infrastructure components. In addition, DR requires network connections from the main site to the backup, and software to give the backup system current information.

Appropriate staff members need to understand how to invoke backup processes. An inventory will determine what systems are used and which employees should change the failed system over to the backup. DR responsibilities include notifying their network and system providers about the change and ensuring employees know how to access the recovery system. Ideally, business users are only affected slightly. The IT team needs procedures for provisioning up-to-date backup information to workers during recovery.

IT departments often spend a lot time setting up and breaking down the physical DR computing environment, rather than coding and testing to add value. To test a DR plan, the data center team requisitions, receives, racks, stacks and configures hardware along with its associated operating systems and any recent patches. They create user accounts, deploy the framework or applications' server environment and install testing tools. Programmers can spend half of their time on mundane infrastructure issues rather than actually testing the application.

Because the process is complicated, enterprises typically test their DR plans sporadically -- once or twice a year. The larger the company, the more complex this DR planning process proves.

Once procedures go into place, they quickly become outdated. Application mixes constantly change, so the team must review and update DR procedures on a recurring basis. Large companies can spend hundreds of staff hours and upwards of seven figures ($1,000,000+) putting each element into place. It costs even more to ensure that plans remain viable.

Many businesses only pay lip service to DR. To spend a great deal of time to mitigate a 1% -- maybe even less -- risk of a catastrophe doesn't seem like a good return on IT investments. IT managers have a long and growing list of daily priorities, and DR is only important when a disaster happens.

DRaaS options

Cloud services save money by running on shared infrastructure. Cloud's virtualization and automation advances enable more flexibility. Businesses use cloud resources as needed, for all or just critical applications. DR tests occur easily by spinning up temporary instances.

With cloud-based disaster recovery, programmers no longer toil at the bits and bytes level; they work above hardware and operating system interfaces. Consequently, IT automates more tasks, productivity increases and DR testing time decreases. The data center staff can test the entire DRaaS functionality more regularly or allocate more resources to high-priority projects.

Because of the benefits, interest in cloud DR services is rising: It will grow from $640.8 million in 2013 to $5.8 billion in 2018, a 55.2% compound annual growth rate, according to predictions from analyst firm Gartner Inc., based in Stamford, Conn.

The vendor playing field for disaster recovery as a service is varied. Horizontal cloud suppliers such as Amazon Web Services, iland, IBM, RapidScale and Verizon compete against DR specialists like Axcient, Bluelock, Seagate's Evault, Net3 Technology, Unitrends' PHD Virtual Technologies, Quorum, SunGard, Windstream Communications and Zerto to host enterprise DR.

When a cloud becomes a storm

There are limitations to disaster recovery as a service.

"Cloud DR vendors do not have complete system redundancy," said Rachel Dines, DR analyst at Cambridge, Mass.-based Forrester Inc.

Suppliers cannot justify the cost of building data centers that mimic each customer's infrastructure setups, so they take shortcuts. A DRaaS provider will build out systems to handle a limited number of outages. Theoretically, a business would recover its system if it encountered a site-specific problem, such as an electrical outage in the data center. However, if a major natural or manmade disaster occurred, there may not be enough room at the DR site to run every DRaaS user's applications. Since the IT organizations at stake would only find that out when the disaster occurred, there is a greater degree of risk to disaster recovery as a service than traditional DR builds.

Cloud-based DR also increases enterprise network bandwidth needs. Disaster recovery as a service places copies of apps and virtual machine (VM) images in the provider's cloud. As those apps and VM images are constantly updated, information shuttles from the enterprise production site to the DRaaS supplier's data center. This load may strain available bandwidth. DRaaS works well with simple apps but may degrade network performance with process-intensive systems, such as customer relationship management and enterprise resource planning apps.

About the author:
Paul Korzeniowski is a freelance writer who specializes in data center issues. He has covered technology for two decades and is based in Sudbury, Mass. paulkorzen@aol.com

Next Steps

Learn about DRaaS vendors and potential pitfalls of service-based DR

Discover how to prepare an enterprise network for cloud-based services

This was last published in February 2015

PRO+

Content

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

Essential Guide

Building a disaster recovery architecture with cloud and colocation

Join the conversation

4 comments

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.

Did you eliminate your traditional DR plan altogether, or add DRaaS functions selectively?
Cancel
We decided to change our traditional DR plan following significant shortcomings such as high cost and complexity both in configuration and testing. Rather than eliminating it altogether, we deployed DRaaS, which is cloud based and is less expensive compared to the traditional DR. With this one, we can test regularly and keep up to date with changes in the industry. This means that data center staff have time to concentrate on other high priority projects.
Cancel
Traditional DR infrastructure could you used concurrently with the Cloud DR. companies would have existing DR infrastructure, and the change should be gradual
Cancel
Cloud DR services in my opinion, has really helped many IT departments, there was a lot of fear initially, resulting to many Data Recovery tactics being deployed. Most of these tactics have been ineffective and the IT department spent most of their time on prevention strategies rather than their actual work. The fact is Cloud storage is still risky, but the advantages far outweigh the controllable limitations. This is definitely the right direction to take.
Cancel

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseLinux

SearchServerVirtualization

SearchCloudComputing

Close