Disaster Recovery Planning Considerations for LANs/WANs

ByJeanne D. Powell, CDRP

The devastation of people’s lives and or businesses because of disasters, such as the Kobe earthquake and the Internet break-in, have become frequent front page news. As recently as 10 years ago corporations gave little time, thought or money to disaster recovery planning. Now, most business people are at least aware of the need. The time, thought and money are following at a slower pace than many of us would like, but at least contingency planning is a possibility. Curiosity of the subject is spreading quickly.
Planning for anything requires a framework. Planning for a successful disaster recovery has the following elements, not necessarily in this order:

•Justification
•Business Impact Analysis
•Risk Analysis
•Critical Application/Function Definition
•Recovery Plan Development
•Recovery Plan Test
•Recovery Plan Maintenance

Local Area Networks (LANs) and Wide Area Networks (WANs) have some unique considerations when writing a disaster recovery plan. Obviously, the hardware and connectivity is a big concern, but businesses are run by people using these inanimate objects, not the other way around. Keeping the big picture envisioned is a sizable challenge, but without the whole picture, important things get lost while we are consumed by the details. You can work on a piece of the pie as long as you keep in mind what the entire pie looks like.
Documentation is the most important step in disaster recovery planning. Without it you are lost, especially in this high-tech world. If you do not know what you have got, you can not replace or recreate it when it is lost. And that’s really the bottom line in disaster recovery planning! That means taking the time to document the obvious, as well as the not-so-obvious. There’s a lot of specific information inside of people’s heads, and not written down. What if these people are not available in a disaster? What is perfectly obvious to one person may seem like quantum physics another. Therefore, it is important to write things down in “see Dick and Jane run” language with no assumptions.
What to document for LANs/WANs? Let’s start with the LAN hardware. A local area network (LAN) consists of one or more servers and one or more work stations. Servers typically store and provide most of the network management, applications, programs and data to the attached work stations. Generally, the server has some unique features, but all PC’s have the same documentation requirements.
Document the maker and the type/model of the PC (i.e. EISA, ISA, Micro Channel©, etc.). It is important to know the specifics such as the processor type (i.e. 386, 486, etc.); the memory type and amount; all the additional feature drivers/types (i.e. IBM©, SCSI); any addresses, switches, and jumpers; monitor and keyboard types plus any unique attachments. Attachments can be hard disks, tape drives, CD-ROMs etc. Note the different types of connectors, cables, terminators, switches, etc. Record the connection types (i.e. 10baseT, twisted pair, etc.); connection device (i.e. MAU, CAU, etc.); communications driver maker/types and the type of terminators needed, if any.
All this information for a PC will be of marginal value without the configuration. Things like the locally administered address, shared storage windows, interrupt levels, ROM addresses, RAM size, Token ring speed, etc., will determine its usability.
Most of the adaptor settings and memory allocation specifics can be gathered by using a utility program (i.e. qconfig for PC-DOS, MSD for MS-DOS, reference diskette print screens for PS/2’s, etc.). A disaster is NOT the time to start all over from a cold install and struggle through the frustrations or configuring a PC. What little sense of humor you might still have after the disaster will certainly be lost during an unplanned configuration exercise.
Assuming any old 486 PC with 16 MB RAM and a Token Ring© card is all you will need to recover in a disaster is playing “you bet your business”.
The details of the features and configuration are immensely important and can not be overlooked. The time required to discover and build the hardware and recreate the configuration can be devastating to a business. Remember, you can not just go and look at what you’ve got back at the office, because it may not be there.
The attached devices (i.e. hard disk, tape, CD-ROM, printer, modem) need to be inventoried as thoroughly as the PC’s. List the quantities, connection types (i.e. fast and wide), driver maker/types (IBM© Multiprotocol adapter, etc.) and compatibilities, address switches/jumpers and terminators, if required. Include any specific supply items (ribbons, fonts, paper, tape size, format, etc.) and their source or vendors.
Routers and gateways are not just PC’s, but are used frequently to direct connections from one LAN to another. Catalog the router and/or gateway maker and type, cables, connection types, consoles and printers, if attached. Like a PC, routers and gateways have connection configurations which determine how, what, where and with which LANs they communicate.
Copy the configuration to a file, back it up and/or print it. But most of all, make sure the configuration information is written down. The potential for career limiting words and actions can be quite high when recreating all the connection and configuration information in a router or gateway.
Backing up the operating system, network manager, applications, programs and data on each server and/or work station regularly is the biggest and most important part of recovering your LAN. After all, if you don’t back it up you can’t restore it! And you can’t restore it if you don’t know exactly what you need to restore and how.
Again, writing and restoration instructions to a “see Dick and Jane run” level helps ensure everything needed is restored successfully. As long as you are writing, be sure to catalog each PC’s software. Record the operating system and level (i.e. DOS 6.0, OS/2© 2.2, Mac©etc.) and any/all prerequisites, co-requisites and dependencies (i.e. DOS 5.1, 16MB memory, etc.).
Many software vendors are protecting their copyrights with serial number specific hooks, so include instructions on how to get a circumvention from the vendor. Catalog your software products, levels and licenses, just in case you need to replace them.
A diagram of a network is worth more than a thousand words. It can provide a level of clarity not easily achieved any other way. Diagram host direct connections, as well as local and wide area networks. At the appropriate places on the diagrams, note the network protocols (i.e. V.35, X.25, etc.); line speeds/bandwidth (i.e. 9.6Kb, 320MB, etc.); line types (i.e. analog, leased, T1, on-demand, etc.); interconnection architecture (i.e. APPN©, TCP/IP, NetBios IPX, etc); local connection architecture (i.e. 3270, ASCII, Token Ring©, Ethernet©, etc.); connection devices (i.e. 10baseT, fiber, twinax, etc.). Document any mux, channel bank, and/or modem settings (i.e. NRZI, DCE clocking, IP address, etc.). List the carriers, the circuit numbers, dialup telephone numbers (switchboard connections) and your carrier contacts.
All this documented, backed up and diagrammed information and data needs to be included in the business’ overall disaster recovery plan. It is vitally important to keep everything off-site and available. Off-site storage vendors are equipped to provide your business a protected storage facility, security and 24-hour access. A bank’s lock box may be a secure place, but most are not available after hours or on weekends and “Murphy” can strike anytime. Ensure all the key players in the recovery effort have a copy of the entire disaster recovery plan. Keep multiple copies of your backup, just in case one is bad.
A disaster recovery plan, by itself, does not ensure a successful recovery. You still need a place to go with some or all of the stuff you’ve documented to recreate and restore your business environment. Do you go to a hot-site, cold-site or mobile-site (with or without a predefined destination)? Will you have everything available at the time of the disaster? Will the equipment match your needs (remember the features and configuration)? Will you purchase everything at the time of the disaster (usually cost prohibitive)? What about a combination of these?
What about the site? Is it far enough away from your location that the same disaster will not effect it? The Kobe and San Francisco earthquakes affected large geographic areas. Does the site already have power, cabling and phones (the kind and as much as you will need)?
A mobile-site usually needs a “hitching post” with power and telecommunications sources. If you are considering a cold-site or mobile-site, power, cabling and phones may not exist or may only partially be in place. Do not expect the utility companies to respond with your level of urgency, things probably will not get done overnight. What about furniture and office machines for our people?
Planning for a successful disaster recovery is always complicated! It takes time, participation from everyone, money and endurance. Once a plan is in place, it needs to be tested, actively maintained and followed. If allowed to get too far our of date, all your planning efforts will be of little value. Things change quickly and the disaster recovery plan must be updated regularly.
We have only touched on a few areas of consideration in just one aspect of a business’ recovery, LANs/WANs. Your business information is located in lots of places and on lots of different media.
Keeping a business going during and after a disaster requires a plan to follow, a place to go, the business’ information and the business’ people to manipulate and utilize that information.
Take heart in knowing others have conquered the obstacles and frustrations of contingency planning and businesses have successfully recovered from disasters, thanks to their efforts.

Jeanne D. Powell is an Advisory Business Recovery Specialist with IBM Business Recovery Center in Dallas, Texas.

Disaster Recovery Worldİ 1999, and Disaster Recovery Journalİ 1999, are copyrighted by Systems Support, Inc. All rights reserved. Reproduction in whole or part is prohibited without the express written permission form Systems Support, Inc.