Welcome to the Danger Zone

Every so often, I get the urge to write about disaster preparedness. This is probably because I grew up in coastal south Louisiana, where hurricane season is frighteningly real. With the southeastern United States digging out from the aftermath of Hurricanes Charley and Frances and preparing for the probable visit of Hurricane Ivan, now seems like a good time to review some simple steps you can take to help prepare your messaging system--and thus your organization--for disasters.

I won't insult your intelligence by telling you to make good backups. (That's such a basic part of messaging operations that no one needs to be reminded, right?) Instead, let me start by asking some questions.

First, where do you keep your backups? If they're near your servers, anything bad that happens to your servers will likely also happen to your backups. You don't need to keep all your backups offsite, but keeping at least some backup tapes in a secure offsite location is a good idea. Your safe place can be as simple as a fire-rated media vault (not an ordinary fire safe, which won't protect tapes and disks) at your house or as elaborate as a secure facility operated by SunGard, Iron Mountain, or another data-recovery/business-continuance company.

Second, how will you tell your employees what to do when a disaster occurs? Surely everyone who works in an area hit by a hurricane (or a fire, mudslide, earthquake, or tornado) will know what's happening outside, but they might not know what's happening inside your organization. Is the office open? Closed? Do certain employees need to report anyway (a common requirement in manufacturing environments in which plant machinery can be damaged or destroyed if not tended continually)? You probably can't count on using your messaging system to get this kind of information out to employees; your servers might be on fire, under water, flying through the air, or otherwise unavailable. One alternative is to use a system such as MessageOne's Emergency Messaging System (EMS), which lets you quickly send emergency notifications to preregistered alternate addresses and switch your incoming MX records over to the vendor's hosted server. That way, users can still send and receive email without using your servers. Similar tools from Dialogic Communications (among others) can automatically send prerecorded telephone messages. This approach is helpful for notifying employees but doesn't give you any ongoing messaging capability.

Third, what about resuming operations? Will you continue operating in an alternate location? You can plan for this in a variety of ways, ranging from setting up full-blown, geographically dispersed clusters to planning to express-mail backup tapes to an alternate location and use Exchange Server 2003's Recovery Storage Group feature to restore messaging service. Alternate-site recovery planning involves too many considerations for me to cover here, but if you're seriously interested in being able to move your Exchange operations to an alternate site, I suggest you read Jerry Cochran's excellent book "Mission-Critical Microsoft Exchange 2003 Server: Designing and Building Reliable Exchange Servers" (Digital Press, 2003). Then consider which technologies and tools make the most sense in light of your availability requirements and budget constraints.

As a final thought, don't forget that your hardware and bandwidth service agreements probably contain language about "acts of God," so if your area is hit by a major disaster, don't count on getting the immediate service you've paid for. Have alternatives ready if such events are likely to be a problem for you.

Riding out disaster isn't a cheerful subject, I admit, but it's important to think of how your business will handle it. And while you're thinking about it, I encourage you to consider donating to the Florida Hurricane Relief Fund (http://www.flahurricanefund.org) or the American National Red Cross (http://www.redcross.org).

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish