For Complete Disaster Recovery, Data Replication Is Not Enough

Timothy Sheets
Slide Show

Five Business Continuity Myths

Avoid these five misconceptions to remain truly prepared.

Tim Sheets
Tim Sheets is Director of Product Management for FalconStor Software.

In today's world, the "I-want-it-now" environment and expectations highlight a long-standing problem in disaster recovery (DR). For too long, IT has accepted data replication as a stand-in for actual DR. Yet, to the contrary, in a post-disaster scenario, almost any business will tell you that replicated data isn't enough to satisfy the "I-want-it-now" expectations of end users. And it's easy to see why. When a technological problem or an act of nature takes down a data center, the availability of mission-critical data - usually offsite - is a business imperative. We all know a hurricane can be bad news. But the loss of all your sales information is a catastrophe.


However, the availability of that data is a separate issue from the act of recovering from the disaster. True recovery returns not only information but also infrastructure and services to their original state. After all, what good is the data without the infrastructure to use it? If IT is to satisfy the "I-want-it-now" mandate, we need to demand more from DR.


What should be on that list of DR demands? For starters:


1. Disaster recovery must address infrastructure needs.

All of that replicated data is useless if your users can't access it in a meaningful way after a shutdown. DR should include procedures and processes for bringing hardware, software, networks and facilities back on line. This goes well beyond bare metal, servers, storage and networks. We are talking about the OS, applications, configurations, settings, management and policies. And the list goes on. In essence, this is a service issue, and data protection and recovery solutions should be as service-oriented as the businesses that rely on them. In order to meet service-level agreements after a disaster, an IT organization needs more than replicated data. It needs business application recovery and intelligent awareness of all IT service components.


2. Service-oriented data protection is essential to maintaining business continuity.

When a data center moves to service-oriented data protection, it begins thinking about each IT service and what it includes. Take your average Web portal, for instance. The portal is not LUN 32 alone; it also includes an Apache server, a SQL database, a content management application and other components. When the data center team views and manages the Web portal service as an integrated element that must be protected in its entirety, recovering that element after a disaster becomes possible more quickly and with greater ease. Service-oriented data protection is application-aware. It knows how to copy data from a database or email application in a system- or state-coherent manner. In other words, it performs DR with the "I-want-it-now" user in mind. When the time stamps for all key components are the same and the data is properly collected, the entire service can be moved or recovered without error or corruption, and without unacceptably long delays.


3. Automation is paramount to quick, complete recovery.

If your DR plan consists solely of data replication, your IT team faces a difficult challenge post-disaster. In such situations, data center staffs bear the complicated, manual tasks of rebuilding servers, installing operating systems and applications, configuring networking, assigning storage volumes, and making sure things start properly and in the correct order. No doubt, you have a skilled team capable of such work, but under pressure from the "I-want-it-now" crowd, even the most seasoned professional can make a mistake. Not to mention that this approach takes more time to do for each IT service, adding to the overall time to recover and extending what we call the "recovery time objective," or RTO. We all know that time is money. Downtime is not a matter of "if" the event will cost my business, it is a matter of "how much" it will cost. When businesses have reliable recovery automation, they can restore each component of service in a particular sequence in a reasonable amount of time, meeting service expectations and avoiding the risk of error that comes with manual infrastructure recovery. In the end, the difference in approach and service level restoration between data replication and true automated disaster recovery can literally impact staying in business or going out of business.


There are other capabilities IT should seek out for better DR. Most businesses need systems that can accommodate physical as well as virtual servers. The best options will integrate easily into existing infrastructure and will work with any storage or networking solutions. You'll likely be happier in the long run if you pursue an open, integrated architecture that saves you from vendor lock-in. All of these things are important in a total, true disaster recovery solution. Whether your list of demands is short or long, though, it must take into account your end user and his expectations for availability and service. It is IT's job to meet those expectations, and mere data replication can't get that job done.

Add Comment      Leave a comment on this blog post

Dec 14, 2011 9:36 AM Aditya Aditya  says:

Great article and advice on data recovery and business continuity,data recovery models leveraging the benefits of cloud computing can provide a scalable recovery model for mission critical data.Just read an interesting white paper Protect against a potential disaster with an effective business continuity plan @

Dec 29, 2011 9:03 AM Jim Jim  says:

Good article.  As for: "What should be on that list of DR demands"?  I think a partial or full DR test on a regular basis with full Root Cause Analysis if failures occur.  How many of the structures we design in IT work perfectly the first time? DR plans are no different.  They need testing.

Jan 2, 2012 1:07 AM Karen Morrissey Karen Morrissey  says: in response to Jim

DR testing is essential. At my most recent employer tested at least 4 times per year, including a no notice or "surprise" test annually. One annual test was audited and part of reporting to interested customers, the others were all to help find problems -- and there are always problems; count on it.


Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Resource centers

Business Intelligence

Business performance information for strategic and operational decision-making


SOA uses interoperable services grouped around business processes to ease data integration

Data Warehousing

Data warehousing helps companies make sense of their operational data