You have to understand these dependencies and include them
in your disaster recovery planning in order to know exactly what
has to be recovered – and in what order – to meet your RPOs and
RTOs. They will also play a role in determining your RCOs.
Where should my disaster recovery
site be located?
Location, location, location – it’s arguably more important in
disaster recovery than in real estate. Your disaster recovery site
should be located in one of the following places:
Out of range of the same disaster. You want to ensure, to the
greatest degree possible, that the same regional disaster – flood,
power outage, physical terror attack, etc. – can’t impact both your
production site and your disaster recovery site. That means your
disaster recovery site should be in a different flood zone, on a dif-
ferent power grid, and serviced by a different telephone network
than the production site. Beware of ‘rule of thumb’ distances such
as 500 or 300 miles. For example, during the World Trade Center
disaster, disaster recovery sites across the river in New Jersey –
just a few miles away – met all three of these requirements.
Within reach of your recovery staff. Disaster recovery doesn’t
just happen. You need staff on hand to help with the implementation. Will your disaster recovery site be in or near a city where
you have staff who can help work on the recovery? Can you get
them to the site if air traffic is shut down or public transportation
is disabled or otherwise unusable? Can the staff be housed there
if they have to stay for a while? The proximity of staff to your
disaster recovery site can determine whether or not your recovery
gets under way at all, how quickly you recover, and the cost of
Close enough to meet RPOs (particularly short ones). It’s easy
to forget that data takes more time to travel longer distances. If
you need synchronous replication to meet your RPO or RTO –
that is, if you can’t tolerate any downtime or data loss – your
disaster recovery site may need to be as close as 150 kilometers,
or 93 miles, from your production site.
What connection size (bandwidth)
do I need between my product and
disaster recovery sites?
The answer to this question is rarely on connection size. More
than likely you’ll need to vary, or throttle, your connection size
depending on what you’re doing over the connection:
Seeding. This is the initial process of recreating your production
infrastructure at the disaster recovery site. This involves moving a
LOT of data. The more bandwidth you have, the faster you’re actually
protected by the disaster recovery site (and the less “catching up”
you’ll need to do during the seeding period).
Transmitting/replicating changes. Once you’re set up, you’ll need
enough bandwidth to transmit the volume of changes in time to meet
your RPOs. If you have synchronous replication for any applications,
at a minimum you’ll need enough bandwidth to transmit that data.
You’ll also need to throttle up from that for periodic (hourly, daily)
Reseeding. If an application or database at your disaster recovery
site is corrupted, you’ll need to throttle up to reseed that lost data.
Failing over. When you declare a disaster and fail over to the
disaster recovery site, you’ll need enough bandwidth to run your
business from the disaster recovery site.
Coming back. At some point you’ll want to take IT operations back
to your production site, and you’ll need enough bandwidth to reseed
your production environment from the disaster recovery site.
;What compliance and security
measures have to be in place at my
disaster recovery site?
Disaster doesn’t excuse you from HIPAA, Sarbanes-Oxley, or
other regulatory compliance requirements. In fact, part of your
compliance may be to ensure that any disaster recovery infrastructure you establish meets the same or similar regulatory
requirements as your production infrastructure. Otherwise you
could be penalized for non-compliance, even if you never declare
Your disaster recovery site may also need to meet security,
data privacy, or monitoring standards or requirements specific to
your industry. While these standards may not carry costly penalties for violation, not meeting them could be costly to your company’s brand or reputation and may cost you customers.
;How often do we need to exercise
our disaster recovery strategy?
If you don’t exercise your disaster recovery strategy, it’s not
really a disaster recovery strategy at all. Unless you exercise you
can’t be certain if you’ll recover from outage or disaster. You
should exercise twice per year at minimum. Your infrastructure
likely changes frequently, and IT staffers’ roles often change or
they leave your company. Exercising at least twice a year helps
ensure your disaster recovery strategy accounts for these changes.
This doesn’t mean you have to exercise your entire infrastructure
twice each year. Larger companies may only be able to exercise
subsets of critical applications at a time.
Be sure to test your network “plumbing” before conducting
any disaster recovery exercise. If your network isn’t working, the
exercise will take longer, cause more disruption, and cost more.
Also be sure to conduct mock disasters which simulate recovery from a full-blown disaster. This is particularly appropriate for
large companies, typically exercise-only portions, of their infrastructure at a time, or for production sites running a higher risk
of natural disaster. Conduct the exercise during a slow business
period to give your staff valuable experience on which to draw,
should an actual disaster ever occur.
David R. Alvarado is the regional director of service delivery for Peak 10.
Alvarado has been an industry leader for more than 35 years leading worldwide organizations in business continuity/disaster recovery and storage for
Comdisco, Storage Tek, and Computer Associates. He is a highly experienced management executive with an exceptional track record at creating
and maintaining successful business models, directing high-performing consulting and
engineering teams formulating strategic partner relationships.