For an Adobe Acrobat format version of DCH's Existing Infrastructure, click here.

Picture the consequences of a system outage caused by a hurricane, flood or even a more mundane utility mishap. What happens when your site is flatlined for days or, worse, for weeks? Think of the lost revenue--and lost customers. Now, imagine that you have planned for and implemented a recovery site: Think of all the positive publicity and new customers you can generate, especially if your competitors aren't as well-prepared.

Planning an adequate business-resumption strategy may be one of the most misunderstood areas of network operations today. It might help to think of a business-continuity plan as an insurance policy you actively avoid cashing in on. And like insurance policies, business-continuity planning embraces a sea of options involving a wide variety of network-recovery schemes, application software issues, operating system software suites, and public and private networks to maintain. As the business-continuity market grows and vendors vie to serve midsize corporations and departmental operations, network managers will find it increasingly difficult to appreciate what competing products offer. Simply stated, there are five areas you must address in any disaster-recovery plan:

· Decide which systems are important enough to include in your continuity plan. The reality is that all systems are not created equal and not all are absolutely critical. Sheer cost will likely preclude incorporating each and every system in your corporate network.

· Ensure that the recovery site does not share any common point of failure with your production site. Make sure the two sites are geographically dispersed so they won't be prone to the same risks of natural calamities, utility infrastructure mishap, civil unrest and so on.

· Determine how to keep the recovery site up to date. This may mean anything from regular, manual backups to real-time replication.

· Plan how users and associated systems will switch over from the primary site to the backup site. For this step, consider both public and private interfaces.

· Finally, outline how all users and systems will "go home"--that is, switch back to the primary site after service has been restored.

To illustrate the approaches that are possible with a business-resumption infrastructure, we presented a challenging disaster scenario to several leading vendors in the form of a Request for Proposals (RFP) for a hypothetical retail company, Dewey, Cheatham & Howe (with apologies to "Car Talk" and the Three Stooges). For RFP details, see "Highlights of the Disaster-Recovery RFP". You can read vendors' unabridged responses at www.networkcomputing.com/1001/1001f1.html.

Three vendors--Comdisco, Exodus and IBM Corp.--prepared responses to our RFP, and all three companies acquitted themselves admirably. SunGuard declined our invitation to participate, citing its unwillingness to disclose prices in a public forum and a lack of resources. Several other vendors also decided not to particpate for various reasons.

All three respondents concluded that a shared recovery approach--in which multiple customers share a single resource (for example, bandwidth, CPU or storage)--is inappropriate for DCH. Although this approach might save money, conflicts can occur if more than one customer declares a disaster and all parties attempt to use the same recovery resource.

Instead, Comdisco, Exodus and IBM all proposed adoption of a dedicated resource path. This means that DCH will share the facility infrastructure (electricity, environmental controls, loop facilities and Internet bandwidth) at the standby site with other parties, but will own or lease all of the facilities it will need during a disaster and to maintain its hot site.

This approach is not necessarily as daunting as it might seem at first blush because DCH began with standby servers and has the replication and operational standards necessary to support hot-standby gear. All three vendors built their solutions around this set of capabilities. The crux of all the solutions is to extend the database replication to and from the hot site.

Despite these similarities, the proposals veer apart in strategic details, with each representing a different sort of disaster-recovery strategy. They also cover a wide (though universally high) cost scale and recommend varying amounts of capacity, layers of redundancy and effort on DCH's part, all of which can have a far-reaching operational impact.

For providing a more-than-adequate technical solution coupled with an exemplary disaster-recovery plan, Comdisco gets the bid. IBM came in a strong second and would have been first if we had given more weight to price considerations. However, we are not so naive as to think that our scenario will perfectly match your own site's needs. To prepare yourself to address the issue of disaster recovery, we strongly urge you to read the full RFP carefully, analyze the responses and the particular costs associated with each strategy, and determine which aspects make the most sense for your own particular configuration of infrastructure, exposure and tolerance for risk.

As you adapt the solutions to your own unique scenario, let your imagination run free. Combine the best parts of all the plans--say, meld the use of an Internet VPN (IBM's idea) with load-balancing to leverage and constantly exercise the hot site (Exodus' angle), and then outsource some of the replication headaches to a storage area network (Comdisco's suggestion). By thus examining the RFP solutions (presented here in alphabetical order), you will be better able to plan for your own day of reckoning.