DISASTER RECOVERY 
JOURNAL

P. O. Box 510110
St. Louis, MO 63151
(314) 894-0276 
Fax: (314) 894-7474
Internet www.drj.com 
E-mail drj@drj.com

EXECUTIVE PUBLISHER
Richard L. Arnold, CBCP
richard@drj.com

EDITOR-IN-CHIEF
Jon Seals
jon@drj.com

SENIOR EDITOR
Janette Ballman
janette@drj.com

ASSOCIATE EDITOR
Ed Pearce, CBCP
ed@drj.com

ASSISTANT EDITOR
Pamela Clifton
pamelaclifton@hotmail.com

COPY EDITORS
Jim Hammill, CBCP
Richard Sandhofer
richards@drj.com

ADVERTISING 
Robert Arnold
bob@drj.com

_____________

Corporate

President/CEO
Richard L. Arnold, CBCP
richard@drj.com

Vice President 
Robert Arnold
bob@drj.com

CONFERENCE COORDINATOR
Patti Fitzgerald, CBCP
patti@drj.com

CONFERENCE REGISTRAR
Merce Knese
mercedes@drj.com

CIRCULATION
Laura Baugh
laurab@drj.com

EXECUTIVE COUNCIL
Mike Croy, Forsythe
Jeff Dato, MBCP, KPMG
John Jackson
Edward S. Devlin, E.S. Devlin & Associates
James Hammill, CBCP, JMH Consulting Inc.
Pat McAnally, SunGard Availability Services
Brian Turley, Strohl Systems
Belinda Wilson, Hewlett-Packard


INTERNATIONAL
CONTACTS
England: Thom Hetherington
Business Continuity
Phone: 0161-237-1007
thomh@tempus.demon.co.uk
Japan: Shinji Hosotsubo
Crisis Management and Preparedness Organization
Phone: 03-3519-6270
fax: 03-3519-6255
hosotsubo@cmpo.org
Brazil: José Carlos Ferreira
Disaster Recovery Mercosul
Phone and fax: 011-3666-9506
jocaff@uol.com.br

Click Here for a Printable Version

Acronym Soup

BCP, DR, EBR – What Does It All Mean?

By MICHAEL CROY & JAMES E. GEIS

With all the terms and abbreviations being used today regarding risk management – BCP, DR, EBR, RPO, RTO, SLA, etc. – a conversation about data protection and risk mitigation sounds like a bowl of acronym soup. And this stew of confusion is peppered with an urgent sense that such matters need to be addressed PDQ. In fact, major technology decisions are currently being made in an attempt to respond to pressing issues. But, at the same time, many still ask, “What does this all really mean? Why are people trying to sell me on a business continuity plan when we already have a solid disaster recovery solution in place? We bought four terabytes of storage this year, implemented a new storage area network (SAN) with all the built-in bells and whistles, and I back-it-up-to-tape. Isn’t that a disaster recovery solution?”
Viewing risk management through a clear broth rather than a pea soup requires keeping just a few basic distinctions in mind.

‘Backup and Restore’ Is Not Disaster Recovery
Backup is an operational process to capture a point-in-time instance of data from a source storage-medium to a target storage-medium so that the instance can be quickly and easily accessed or retrieved. The target medium can be tape or disk, remote or local. Generally, when you back up, you capture a benchmark, statistic, or metric to determine and verify the point in time, and include a process to quiesce or close open files to ensure that you have a clean backup. Sometimes disk “snap” or “clone” technologies are used to aid in the backup process, as well as “hot” backup features with some software.

When retrieval is necessitated in the daily course of business – in response to either a planned or unplanned event – it is called restore. To restore (not to be confused with recovery) is simply copying the data from the target back to the original source. Planned events might include refreshing a testing and development environment with current production data or a disk de-fragmentation. Unplanned events range from data corruption (of one or more files, file systems, databases, tables, indexes, etc.) and accidental deletion (including by user error) to application and hardware failure, facility disasters such as power outages, and catastrophic disasters such as flood, fire, or tornado.
If the retrieval is in response to a catastrophic event, it is part of a larger disaster recovery effort, supported by back-up and restore processes. The reality is that backups are done to facilitate both restore and recovery in the event of any business interruption, large or small. Recovery generally includes numerous operational steps and a process that involves various staff.

In contrast, disaster recovery (DR) is a risk management discipline. A DR plan must define who will do what, when, how they will do it, and in what sequence or relationship with other dependent procedures. In addition, a DR plan requires a pre-determined recovery time objective (RTO) and recovery point objective (RPO) for each application, process, or dataset. The RTO defines how quickly the operations of the application(s) or process(es) must be resumed for the business to resume function. The RPO identifies the point in time in the data flow that systems need to return to in order to resume operations. The RPO is based, in part, on a determination of how much data the organization can afford to lose, and is matched with the metric determined at the point in time that the backup was captured.
As can be seen, backup and restore is a critical element of DR, but only one element.

Disaster Recovery Is Not Business Continuity
Both DR and business continuity planning (BCP) are risk management disciplines designed to ensure a minimum of turmoil and exposure in the event of a possible business interruption. DR is the reaction to the interruption of a specific business process according to a plan that ensures its orderly and timely restoration. BC is the discipline of maintaining the operation of a business despite interruption of its processes, in whole or in part, regardless of cause or duration.
BC is the proactive discipline of identifying vulnerabilities and risks, and planning in advance how to mitigate, accept, or assign them in the event of a business disruption. BC involves clarifying organizational expectations to close any gaps between achievable recovery time and recovery point objectives and the recovery expectations held by management and the business units.
A comprehensive BC plan goes well beyond what IT needs to do. It encompasses all aspects of minimizing risk to operations and revenue streams in the face of a business interruption. BC planning and execution must include managers and operations people in every area of an organization, including application developers, facilities management, and even the communications department, who must be prepared to ensure that crisis communications are consistent and protective of the organization’s public image.

The Evolution of Business Continuity– A Brief History
Once upon a time, a business ran one application on one server. Data was saved to tapes and restored if and when needed. Changes in infrastructure, namely distributed computing environments, led to interdependencies across infrastructure and across the business units, because business units share applications and data.
The concept of enterprise-wide backup and recovery/backup and restore (EBR/EBRS) has also transcended the old model. As backup, recovery, and restore requirements have increased and time windows have decreased, the process has shifted from a semi-permanent or short-term reaction to an integral piece of a business continuity plan – which is a long way from where it was when it was strictly disaster recovery.

Services and Operating Levels
The services an organization delivers rely upon multiple, interdependent components. In order to meet service and operating level expectations, which are often contractually defined according to service level agreements (SLAs) and/or operating level agreements (OLAs), all of these components must function correctly. Consider, for example, electronic mail. From an end-user perspective, e-mail service is available or it’s not. If it’s not, there are negative consequences for productivity – and worse, potential threats to revenue and company reputation.

E-mail requires that a variety of interdependent service delivery components are all functioning: the compute hardware, operating system, storage, network, electricity, and – of course – the application itself and the supporting middleware applications (see Figure 1). Accordingly, e-mail backup must take all of these components into account – and so must any disaster recovery or business continuity plan.
At the same time, increased infrastructure complexity has complicated data storage questions such as when, where, and why. It isn’t accurate to think of backup and recovery or backup and restore in terms of a single, homogenous enterprise. Successful, cost-effective data storage and backup needs to take into account the business value of different types of information – from instantaneously-required transactional data to reference or archived data – and match storage architecture appropriately.

Viewing IT in a Business Context
While BC, DR, and EBR are often discussed in terms of technology, they are not merely IT functions, but rather, are integral to all facets of the organization. They are interdependent elements of the services that allow the business to serve its customers, provide product, and generate revenue (see Figure 2).
In addition, for any of these elements to be successful – i.e. for an organization to truly ensure the availability, accessibility, and accuracy of its information and information systems – all the people in the organization must understand the goals of each. All means not just the IT staff, but the business and organization leaders who hold the fiscal and fiduciary responsibility for the business units and the business as an entity.
In other words, viewing IT in a business context enables the organization to meet its business goals.

Michael Croy has more than 20 years of experience in building, developing, and implementing disaster recovery and business continuity programs. As Forsythe’s business continuity practice manager, Croy is responsible for the company’s business continuity offerings, including risk analysis, best practice models for continuity of IT infrastructure (storage, server, and network), and disaster recovery planning, strategy, and management.

James E. Geis is director of storage solutions for Forsythe. Geis developed Forsythe’s unique information management framework – the roadmap Forsythe uses for information and storage consulting engagements. He manages Forsythe’s professional services practice focused on information policy, information lifecycle management, tiered and hierarchical storage, operational backup and recovery, and data replication and archiving.

©Copyright 2005 Systems Support Inc. All rights reserved. Reproduction in whole or in part in any form or medium without the express written permission of System Support Inc. is prohibited.