Building a disaster recovery architecture with cloud and colocation
A comprehensive collection of articles, videos and more, hand-picked by our editors
Disaster recovery as a service means more deployment and testing flexibility for enterprises, but also more recovery...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.
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. firstname.lastname@example.org
Learn about DRaaS vendors and potential pitfalls of service-based DR
Discover how to prepare an enterprise network for cloud-based services