| 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
PUBLISHER &
EDITOR-IN-CHIEF
Richard L. Arnold, CBCP
richard@drj.com
SENIOR EDITOR
Janette Ballman
janette@drj.com
MANAGING EDITOR
Jon Seals
jon@drj.com
COPY EDITORS
Richard Sandhofer
richards@drj.com
Pamela Clifton
pamelaclifton@hotmail.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
Jeff Dato, MBCP, KPMG
John Jackson, IBM
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
Australia: Anthony J. Harvey
Journal of Business Continuity
Phone: 0011-613-953-0055-8
fax: 0011-613-953-0528
sector@notability.com.au
Japan: Shinji Hosotsubo
Quake Japan Co., Ltd.
Phone: 03-3215-2880
fax: 03-3215-2881
Brazil:
Jose Carlos Ferreira
Disaster Recovery Mercosul
Phone: 55
11 3666-9506
conc2000@uol.com.br
www.drms.com.br
|
|

Click
Here for a Printable Version
Systems
Continuity On a Shoestring
By J. DAVID HARPER
We are used to thinking of disasters on the grand scale
– massive power outages, fires, earthquakes, and other news making
events. But with information technology resources, even a small event
can have catastrophic, far-reaching effects on a business. The failure
of an e-mail server can wreak all manor of havoc on an organization
that depends on e-mail; the loss of a Web server can cause untold losses
to a company that generates revenue through its Web presence. Internal
data that is vital to the operations of a business can take many forms,
from manufacturing data to customer relations and financial data. Any
company forced to fly blind without access to its critical data is at
a severe disadvantage.
Since a single system failure can have such catastrophic effects, it
is vital to consider the threat of a single system failure when designing
disaster recovery and business continuity processes. Systems continuity,
or the process of maintaining systems access to people who need it during
such an event, requires careful consideration and budgeting. Many IT
managers repine the shrinking of their budgets and pass off systems
continuity with a shrug and a “maybe next year” attitude.
A prevailing philosophy among these managers is that without the requested
budget, systems continuity cannot be accomplished. That is not always
the case. Systems continuity can be possible even under tight budgets
with some refinement of the processes.
If the budget isn’t forthcoming, consider alternative processes,
limited access options, and vendors as three resources to do more with
less in the event of a systems failure.
Considering alternatives requires a keen eye for what is and what isn’t
needed. An active, redundant mail server would be nice, but if the budget
doesn’t allow it what else can be done? Many mail servers will
operate on a desktop computer, but that option is rarely considered.
Is it slow? Of course. Will it handle all the mail traffic? No. But
if it will allow those who most need their mail to have it on demand,
and for others to retrieve their mail once or twice a day, then it will
keep your business communicating while you rebuild the original.
A laptop with two PC card NICs and the right operating system can route
between two networks. It will be slow, but it will work. And while it
is routing packets you have bought a little time to get the next day
warranty router in to replace the original.
Can’t afford redundant fiber and managed switches in case of a
fiber cut or other campus network failure? How about a phone line in
the remote building and a modem to dial in and connect to the required
systems? Wireless phones are fantastic when the land lines fail, but
they are also well suited to relaying messages to someone who cannot
receive e-mail at a remote location until service is restored. The person
at the front end can read off the e-mail and then respond on behalf
of the recipient.
The point is not to do everything on the cheap, but rather to take responsibility
for making sure your company can continue to operate even when you do
not have the budget to provide everything you would like. It’s
irresponsible to throw up one’s hands and blame the budget. Solutions
must be found, money or no money.
Another critical concern is who needs what, and when? Work with the
various departments to determine exactly what processes must take place
for the company to do business, and exactly who must have access to
what information.
A mistake made by many IT managers is to decide for themselves what
systems, data, and processes are critical to the organization. This
decision should be left to the managers and supervisors on the front
lines, not to IT. Enlist their help by asking questions like, “If
this system were down for two days, how would you continue to operate?
What could we do, either now or then, to make that process easier?”
There are two key advantages to this approach. First, by working directly
with the people who are served by the IT resources, the IT manager is
certain to focus on the systems most vital to the operations of the
company. Second, the managers and supervisors at the front lines may
have other ideas or alternatives available in the event of a system
failure. If this is the case, the IT manager will not need to focus
as much time and resources to provide a solution for that system. This
way, the time and resources available to the IT manager can be directed
only to the most vulnerable areas.
Besides the managers and supervisors around the organization, your best
ally in reducing systems continuity costs may be your vendors. If systems
continuity is not an option due to budget constraints, what about reduced
recovery windows? Would a vendor be willing to loan or rent you a system
on very short notice, even after hours, in an emergency? If so, acquire
the appropriate guarantees, requirements, and contact numbers to make
it happen today.
Consider this option when budgeting projects for the coming year. Rather
than negotiate as far down on price as you can, work on negotiating
such emergency services into your deal with the vendor. Communications
companies may be willing to guarantee better SLAs in exchange for a
slightly higher price than you would have paid otherwise, and product
vendors may be willing to provide after hours emergency support in exchange
for more of your business. If your vendors are not willing, or do not
have the resources to do so, you may want to shop around.
Every business will have different needs, and every need will have different
alternatives. The examples outlined here are only examples, and are
designed solely to start the thought process. If there are systems that
cannot be down, list each one on a sheet of paper and work diligently
until you have found a solution for each.
Of course there are times when real-time active redundancy, and the
expense that goes with it, is the only choice. A company that stands
to lose $1,000 per minute when its Web server is offline will have to
have the best in active redundancy. But if the Web server is generating
$1,000 per minute, that company can probably afford it. For the rest
of us, there are alternatives. We just have to knuckle down and make
it happen.
J. David Harper has been managing networks for 14 years and was a speaker
on disaster recovery at the 2003 CAMUS International conference. He
is currently the network communications manager for a global manufacturing
company based in Central Texas.
To comment on this article, go to 1702-06 at www.drj.com/feedback.
©Copyright
2004 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.
|