What would happen to your business if a disaster
were to strike? What would happen if your business were shut down for a day? For a week? For a month? At some point, if you can't do business, you'll be out
of business. You can't always prevent disasters, but having
a disaster-recovery plan (DRP) can prevent a disaster from
ruining your business.
Also known as a business continuity plan, a DRP outlines
the steps that need to be taken if an event occurs that stops
your business sites from operating. The DRP helps your business continue to function.
Preparing your company to survive a shutdown isn't
simple, but careful planning coupled with follow-through
can turn a potentially business-ending event into a temporary interruption. The Gartner Group has said that 40
percent of business enterprises that experience disaster go
out of business within five years of the event. If you want
to be in the 60 percent of businesses that survive, you must
have a DRP in place before a disaster and follow the plan if a
disaster occurs. (Gartner has done many reports on disaster
preparedness, which you can find at http://www.gartner.com/1_researchanalysis/focus/aftermath.html.)
The complexity of your disaster preparations depends on
several factors, including the size of your business. In most
cases, recovering a small business is easier than recovering a
large business. But although a large business might require
a more extensive or complex plan than a small business,
all disaster-planning processes, regardless of the size of the
business, should include the steps outlined in the sidebar "Disaster-Recovery Checklist".
A complete recovery plan includes technical, personnel,
and facilities considerations. I walk through the IT aspects
here, but remember, your plan must also adequately address
crucial facilities and personnel requirements.
Put Together Your DRP Team
The first step in creating a DRP is putting together the planning team, typically a management team that determines
what needs to be in the DRP and designates who's responsible for each part of the plan. In a small business, the DRP
team might simply be the company owner and the IT person.
In a large corporation, the DRP team might be made up
of the department heads or division vice presidents. In all
businesses, the DRP team needs to include people who are
empowered to make key decisions and who know what data
and business processes need to be protected in the event of
a crisis.
In your DRP, you need to address budgetary, organizational, and business-process requirements, and the DRP team must agree on how to handle these requirements. The
DRP team can delegate some responsibilities—for example,
the team might assign certain steps to subordinates whose
expertise covers what needs to be done—but it's crucial that
DRP team members have authority to make the decisions
necessary to implement the complete plan.
Evaluate Your Business Processes
After you have the DRP team in place, it's time to evaluate
your business processes and determine which business functions are "mission critical," which are "must-haves," which are
"nice to have," and those that aren't essential. First, identify
which business processes are needed for the business to
continue in a crisis. Then, determine the minimal technology
resources that your business needs to restore those processes.
Note that although disaster recovery is often expensive, even
in a small company, when the DRP team determines the
minimum requirements, you must be prepared to preserve
resources and not cut any resources below that minimum
level. There's little point to having a DRP that requires
redundant hardware and software systems if someone up the
corporate chain of command decides that sufficient money
or support isn't available for those resources.
When determining what equipment is needed for the
recovery plan, you'll want to point out the investments
that serve double duty. For example, you might determine
that you need to have network servers in reserve, but you
can't do much with that hardware while it waits to be used;
if you put reserve servers into service, you increase the number of systems for which you need to provide redundant
hardware. But you can maximize your investment. Although
hardware such as online and offline data-protection
systems are crucial to your DRP, you can also make them
everyday parts of your IT process. Your recovery plan might,
in this case, motivate the business to add additional capabilities and features beyond what you need for regular
backup and recovery so that the expenditure towards the
DRP is incremental. For example, you might add new
generations of backup and recovery hardware, which
improves day-to-day workflow and improves your disaster
preparedness.
The DRP team also needs to decide what level of catastrophe the business is prepared to recover from. Your DRP might
cover everything from a simple short-term telephony or
networking outage to a full-blown Hurricane Katrina–level
devastation of local public and private infrastructure. However, most plans commonly focus on catastrophes that are
the most likely (fire, flood, weather problems). Be sure to
specify the level of disaster your DRP addresses.
Detail the IT Aspects of
Disaster Recovery
In "Backup and Recovery Basics" (January 2007), we talked about your data backup and recovery plan. You'll want to
include that data plan in your DRP. The data-recovery plan should, at a minimum, cover
the basics of protecting your mission-critical
(and valuable) corporate data. Note that some
items that are optional in simple data-backup
plans may become requirements in DRPs. For
example, your backup and recovery plan will
likely include the ability to restore servers if they
crash. Perhaps you've even provided backup
server hardware. But as part of a good DRP, you
might want the ability to restore servers to nonidentical hardware, which would then require
extra steps in the backup and restore process.
If your business is large enough, your DRP
might include a plan for duplicate data centers,
set up as redundant sites. If your business is
large enough to have multiple data centers, you
might want extra capability at each site to intervene should a data center become unavailable.
In all cases, you need to be able to back up data
offsite so that the loss of the primary location
doesn't mean the end of your business.
Offsite data storage can range from the low
end (an employee is responsible for taking the
daily backup tapes to a secure offsite location)
to the high end (sufficient network bandwidth
is available to allow for real-time data replication to offsite storage). Internet-based backup
and recovery systems can serve a dual purpose,
providing regular backup and recovery services
along with a reliable and secure offsite location
for mission-critical corporate data.
Test and Implement the
Disaster-Recovery Plan
You've decided what aspects of your business to
protect and how you're going to protect them.
Now you're ready to test and implement the
DRP. This means documenting each DRP task,
outlining the order in which the tasks should be
carried out, designating the person responsible
for seeing each task is completed, specifying
who manages the entire DRP operation, and
testing the entire DRP.
After you roll out any additional hardware or
software, you'll want to walk through the entire
DRP, making sure that the planning documentation matches the actual recovery process. This is
the time to make necessary changes to the plan
or to the technology. Remember, as you make
changes, you'll want to re-confirm previous steps to make sure that they still apply. Having a
DRP is not a one-time event: You need to keep
working through the DRP until you achieve
repeatable, consistent results.
When you're certain that the DRP works
and that the documentation accurately reflects
the process, you're ready to have the DRP team
approve the final version of the DRP. Then,
you're ready to distribute the plan as appropriate, in whole or in part, to all affected parties.
Also, be sure you have secure offsite storage for
printed copies of the detailed DRP.
The Ongoing DRP Process
Even though you now have a DRP in place,
you've only just begun the disaster-recovery
process. Very few businesses are static, so as
business changes, your DRP will also change.
As with any business-critical activity, testing and
maintaining your DRP is an ongoing process.
As you add technology to your business, you
must determine how the new technology affects
the DRP, then change the DRP and associated
processes as necessary. Changes in the way you
do business can also affect the DRP, so be sure
that you alter the DRP to reflect any changes
to business workflow. Regularly evaluate your
plan—how often you evaluate depends on
how fast and how often the business changes.
Simply documenting changes is unlikely to be
sufficient. Your DRP should be tightly integrated
into your business model—any changes to the
business also mean that the DRP will change
and need to be updated and re-tested.
The job of the DRP planning team continues as well. The composition of the team may
change somewhat after a functional DRP is in
place, but the DRP team still needs to organize
the management and maintenance of the DRP.
Regularly scheduled DRP team meetings can
give multiple departments the chance to interact and the opportunity to provide recommendations for current and future updates of the
DRP and its processes. Continuing involvement
with the DRP team also helps remind business
staff of the ongoing importance of having an
up-to-date disaster-recovery plan.
Various analysts studying disaster recovery
have noted that nearly 50 percent of all large
companies lack any sort of comprehensive DRP,
with that number climbing closer to 80 percent
when small businesses are included in the
calculation (for more information, see http://www.gartner.com/1_researchanalysis/focus/aftermath.html). Every business, regardless of size, can benefit from having a DRP. Defining
what needs to happen in the event of an emergency lets you gain some control over a crisis
that might otherwise put you out of business. Implementing a DRP, even on a small scale, can
make the difference between business survival
and failure.