TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
At 03:39 PM 4/7/98 -0400, Mary Kunzweiler wrote:
>I need to document a corporate-wide disaster recovery plan.
>Does anybody know the types of info covered in such a plan? I know I need to
>cover topics like "Tornado wipes out manufacturing plants, here's our plan",
>"Bubonic plague keeps 3/4 work force at home, here's our plan" and "UPS
>strike, here's our plan."
... and Beth and Elna pointed out that the focus can't just be about the
disaster, but the *recovery*.
I just dug up my "Miracle Issue" of _Information Week_ for May 15, 1995: I
picked it up on a long lunch hour while contemplating tackling the Disaster
Recovery Plan for the Large Semiconductor Manufacturer I was working at
back then -- I raced back to work with all sortsa fresh ideas -- the
engineer and I were both thinking of military-style DRPs (actually
emergency response procedures: "In Case 'A' can we fly a class of telecomm
operators from Ft. Gordon to replace the ops who have succumbed to nerve
gas? Or did Augsburg get nuked and we need to plug a replacement
comm-center into the net?") the main focus was replacing the physical
assets and personnel of a site that just-got-nuked... the last 30 days'
message traffic is stored in a bunker on punched cards and mag-tape. The
realization that *our* data were stored in the same building and vulnerable
to earthquake, fire, or strike (but not likely to get nuked anymore, thank
heaven!) was a little disconcerting.
_Information Week_ on techweb.com isn't archived that far back, so I'll
summarize and add a note.
1) Identify critical operational information
2) Develop and enact a plan for recovery of critical information
3) Institute a testing and evaluation program (y'know: that lifecycle
methodology we talked about recently might come in handy there)
4) Designate and *deploy* an alternate site for your operations
NOTE: with the ready availability and ease-of-use of new backup media such
as recordable/rewriteable CDs (CD-RW) these days, it's even easier to have
a complete backup of everything -- Beth Agnew said "Think of what the
impact would be on you if you lost the entire contents of your hard drive,"
I just had that happen: lost everything I've written over the last ten
years; and spent several days trying to recover stuff off ten-year-old
floppies (not recommended). Now I've got my System setup, bookmarks,
website and archives backed up on CD-RW *and* CD-R -- remind me to make a
set to keep at dad's house ;-).
At the close of the "Nanosecond Nineties," not only do You wanna be able to
resurrect your operation as soon as possible; you *have* to. It took me a
week to recover 1.5 gigabytes out of the 3.7 gigabytes I lost -- and I had
a project to rev in the middle of it-- I've seen people lose their customer
database by hitting [ENTER] before they should have (and no backups), and
I've seen techs setup a dozen laptops just-out-of-the-box with *one* master
build CD [COOL!] I can only imagine what it would be like if I was working
with a *large* customer after an ice storm cut a branch office out of the
[But, I'm certainly glad that nowadays "getting nuked" means a virus or
spam-flood versus what it *used* to mean ;-) ]