Business continuity vs Disaster recovery

[Mark R]

I'm just wondering what people typically mean by these terms and what the difference is.

We're procuring a new application at work, and we've been having the various reps in to talk about their particular application solution. Various vendors and other staff on the purchase review committee seem to be using different definitions for these terms, so I was hoping to get a bit of consensus.

For example, one vendor offers 2 servers, each with multi-path connections via redundant FC switches to the application-SAN. Optionally, they can provide a 3rd lower-end server with a DAS to provide operation with limited (the most recent) data, and limited performance, in the event that both main app servers or SAN are down.

The other guys at work are now praising the vendor (of quite a poor product) because of their disaster recovery provisions.

I seem to be a lone voice, in saying that it isn't disaster recovery but DR is irrelevant; we are purchasing a "bulk data store" from a 3rd party. This will receive the data from the app servers, and archive it for permanent storage. The application SAN will, in effect, be relegated to the role of cache.

In my view, the DR comes from the bulk store - if the app servers/SAN die, then the system can be restarted with clean servers which will populate from the bulk store.

Amiright?

 

[BoberFett]

I see business continuity as a generic term that can cover both disaster recovery and high availability. Your particular company's demands can make business continuity require more from on or the other.

If your biggest concern a tornado ripping through your datacenter and destroying servers that get updated monthly with new business forecasts then your continuity might depend more on DR.

If your biggest concern is an error prone legacy application that locks up servers on a periodic basis while hundreds of clients are connecting to it every hour, then HA might be more important for continuity.

In your particular case, if the production servers do crash hard, can the data be restored easily from the bulk data store? Or is it designed for one way traffic? Once data has been warehoused it's not necessarily easy to restore the source data from it. It depends on the software.

 

[unokitty]

Information system contingency planning represents a broad scope of activities designed to sustain and recover critical system services following an emergency event. Information system contingency planning fits into a much broader security and emergency management effort that includes organizational and business process continuity, disaster recovery planning, and incident management. Ultimately, an organization would use a suite of plans to properly prepare response, recovery, and continuity activities for disruptions affecting the organization’s information systems, mission/business processes, personnel,and the facility.
--NIST 800-34

Like a lot of terms, different people use these terms differently.

For example, if you were studying for the CISSP exam, then I would suggest that BCP deals with routine business disruptions whereas Disaster Recovery deals with major nonroutine disruptions.

In another context, you might take a somewhat different perspective.

Best of luck,
Uno

 

[Mark R]

I see business continuity as a generic term that can cover both disaster recovery and high availability. Your particular company's demands can make business continuity require more from on or the other.

In your particular case, if the production servers do crash hard, can the data be restored easily from the bulk data store? Or is it designed for one way traffic? Once data has been warehoused it's not necessarily easy to restore the source data from it. It depends on the software.

Your definitions make sense. I guess DR simply means something totally unexpected, where BC means something that is more likely to happen.

Anyway, it's been interesting to see how different system integrators deal with this. One presented their software solution but offered to host it as a cloud service. Rather than simply providing a rack with app servers/SAN/long term store for us to install on-site, they would host complete replicated racks at multiple tier 4 DCs (where there would be a fully managed service) and provide multiple redundant links from our site to each of their DCs.

Anyway, it's going to be interesting chosing between the solutions - I suspect the finance dept may have something to say about the multiple tier 4 DC solution.

 

[alkemyst]

Business continuity is more nothing changes during a failure.

Disaster Recovery is more restoring what you had.


none of this is set in stone though so that is a problem.

 

[ScottMac]

Business Continuity is more than just the data and systems. It covers everything needed to get the business up & running (or in some cases, transfer operations to a backup site before the disaster occurs).

It covers things like replacement office space, employee quarters, power sources (getting / maintaining / fueling a generator, for example), phone & data services, food and other "bulk resources" (ice, water, etc.) availability, maybe even third-party transportation for employees to get them to the new work site ... everything needed to continue operation after something ugly happens.

IT's role is stuff like cabling, active infrastructure, computers, data recovery / connection to backup data or drive images, external access (i.e., Internet), data and system security ... everything to provide information and communication resources to the employee base following something ugly.

Data Recovery is a part of Business Continuity; having the backups / archives are useless if you can't get to 'em. Having computers is useless if you don't have power. Having computers is useless if you don't have a place to use them, or if the employees can't get to 'em.

We have to review and update our BC and DR plans every quarter (minimum) or when Operations processes change. It's a PITA, but when something ugly happens, we'll have the guidelines to get things cookin' again in the minimum possible time. If our competitors can't / don't // won't ... then that gives us a business advantage and (hopefully) elevates our reputation with our customers.