Does the phrase, “Nervous as a long-tailed cat in a room full of rocking chairs,” by any chance describe the manager in your company who includes among his responsibilities a Local Area Network? Let’s take a look at some of the issues involved here and see if we can resolve at least some to that managerial nervousness. In today’s high-stakes, high-pressure business world, you probably want your managers managing proactively and looking well into the future rather than looking to see what evil lurks behind the LAN.
The first thing to realize is that a LAN-based microcomputer system can be a very sophisticated entity. Token rings, file servers, and network design are all things of the present that aid business offices in their relentless search for increased productivity and some kind of a competitive edge. If you have a LAN where you work, chances are you’ll be surprised if you catalog all the applications that reside in the various nodes of the network.
Almost certainly you will find they range from simple spreadsheets through CAD programs to sophisticated market modeling packages. The common denominator of a LAN is the technology, the ties that bind, not the applications. That is the key to protecting your LAN from any type of catastrophe which may befall it. Zero in on the technology you are using, understand its advantages and limitations, and you will have a base on which to build a plan for recovery.
Let’s start with the foundation: backups. Just as in a mainframe environment, if you are not doing your backups intelligently and regularly, you are not serious about recovery--no excuses, no “but it’s different in my shop.” If the people working on their PC’s on the LAN are doing productive work in the first place, take backups faithfully, frequently, and even forcefully if you have to. Back up your data, programs, and anything else that you would like to have when you arrive for the day’s work tomorrow morning.
Is your file server large enough to accept all of the files each LAN user needs to protect? Probably not. And the cost of more storage on the file server will probably be too high to make that approach worthwhile. So educate each person on the LAN in the value, practice, and absolute necessity of doing his or her backups. Don’t make it more difficult than it has to be. Provide instructions. Provide labels. Provide pickup of this backup cycle and delivery of the one coming back. You can even provide encouragement! But be relentless--it’s your responsibility as well as theirs. After all, you are management.
What do you do with this new pile of floppies or 3 1/2’s you’ve just created? Again, we’re back to the basics of data center good practices. Get them offsite. Take a good look at the value of the information on the diskettes. Some of it may be easily replaced or re-keyed, while the recapture of other parts would be more difficult. The loss of some of it may even cause financial loss to your company and embarrassment to any professional worthy of his calling. By taking this look you have just completed an impact analysis. Now you can decide the appropriate frequency for moving your backups in and out of the office. As a general guideline, do not pick a time period greater than one week. Also, give some thought to the day of the week you choose, for it can often make a difference to your recovery time frame.
Because you are performing valuable work on the LAN, it is crucial to move your data offsite, to a proper Offsite Storage Facility. Practically speaking, it should be a small matter to add another pickup to the schedule your company probably has already with one of the offsite storage vendors. Your company’s Operations Manager should be able to help you out here.
Take an inventory of all the equipment comprising your LAN. Include the full configuration of each PC, all the interconnecting cabling, the host micro, and all the software used to run the LAN itself and on the individual PC’s. Think about it. How much of this is off-the-shelf and could be readily replaced if your LAN melts late one night? How much of it is custom-designed just for you and would take an eternity to duplicate? There must be someone somewhere who actually understands its architecture.
Once you have all this data recorded, take stock of your exposure. Is there a company with whom you should contract to help you replace your LAN? Are there certain components you know you’ll need sooner than anyone can get them for you? And are some of the cables unique to your office? If any of the above warrant a “yes” answer, you’ll have to consider buying the articles ahead of time and storing them offsite with the inventory you took.
For the next-to-last step, give some consideration to a possible location for your LAN and the people who rely on it. If your company has a General Office Contingency Plan, this has probably been taken care of for you already. If not, you should looking for some kind of office accomodation which will allow you to reinstall all the new or salvaged LAN equipment and provide its users with a modicum of work and storage space. You’ll need security of some kind for the portion of the building you occupy, and you’ll need the expected office amenities for the staff. In addition, it would be beneficial to have some way of communicating with other parts of your company. Perhaps a few telephones or a courier service will help you in this area.
Finally, do something nice for the people who use the LAN day in and day out. Tell them what you’re planning, ask for their ideas, and listen to what they say and incorporate their thoughts whenever you can. This effort on your part will go a long way towards gaining their friendly cooperation and compliance when it comes to doing those backups in the first place. And that’s where you have to start if you’re serious about recovering your LAN.
Follow these simple guidelines and you need be nervous no longer. Move away from those rocking chairs, curl up that long tail, and relax in front of a roaring fireplace. Your LAN’s safe!
Written by Don Grimwood, senior consultant, Corporate Business Systems, Inc., Toronto, Canada.
This article adapted from Vol. 3 No. 1, p. 18.