Printer Friendly

Designing networks with disaster in mind.

Network disasters come in many different flavors: disk crashes, viruses, cabling problems, power line problems, unauthorized users or uses and, of course, physical disasters such as fires or hurricanes.

When designing a system, its necessary to keep this firmly in mind.

When operating a network, it is only a matter of time before some form of disaster strikes. Prevention steps can help reduce the scope of the disasters experienced. Disaster planning requires a little homework, but it definitely pays off in the long run. This applies whether you are modifying or upgrading an existing network, as I did, or are starting from scratch.

The previous network that I inherited seemed like it was down every other day for one reason or another. The little thinnet network had grown from two users to 12 over the last few years, and word processing was its primary function.

Each time the network failed, we scrambled to bring it back on-line as soon as possible.

As is often the case, when users are responsible for backing up their own data, it generally does not get done on a regular basis. When a disk crash occurs, the network manager ends up bouncing from user to collecting the data needed to recover. When no network-based backup system exists, you reinstall the network and set up all the user profiles again.

When thinnet networks get too big, a wiring problem brings down the whole net. If you don't have a UPS, power line problems will also bring your network down to its knees.

From this experience, and my own past experiences, we set out to build a better and more reliable system. We needed a network which could sustain more users and mission-critical operations.

We began developing the current network about a year and a half ago and spent about three months considering how it would look, evaluating equipment and justifying cost. This was time well spent.

We chose NetWare 386 for the operating system, primarily due to its popularity and widespread availability of applications. Since this system had to provide support for applications developed for customers, we needed a system that would reach the largest group.

The lowest common denominator to any disaster recovery scheme is a good network-based backup system. But without a prevention plan, even that is of limited value.

You must determine how often to back up, at which time of day, full or incremental backups, which files, how often to rotate tapes, where and how to store tapes (an off-site storage plan helps), and how (procedurally) to implement a recovery.

Then test it until it hurts! An untested plan is of equally limited value.

We selected the Maynard Maynstream 2200HS for the tape backup system due to its capacity (2.2 GB) and its ability to run unattended. The 2200HS also allowed for good control over selective file backups as well as a useful scripting language.

In addition, Maynard was developing a NLM (NetWare Loadable Module) which would add a degree of backup flexibility by placing the tape unit physically on the server.

We removed the thinnet wiring and replaced it with thicknet to isolate the workstations and alleviate wiring problems we had experienced previously. We are presently evaluating 10base-T systems for network management as this system grows.

We also installed uninterruptible power supplied to minimize the effects of building power fluctuations and outages on operations.

The file server is an Everex Cube, due in part to the improved cooling system. The file server also contains a Cubix Remote Communications processor card so I can dial into the network remotely for support and after-hours maintenance.

In an attempt to control the infiltration of viruses, the company required the use of a sanctioned virus scanning program on each workstation.

This was augmented by the installation of Sitelock, a software package which was loaded as an NLM on the network.

The bottom line is that these measures do not come cheap, but then you need to consider the cost of lost data. Quite frequently the data is worth more than the sum of the system's parts.

This system has evolved from a simple word processing system to one that maintains equipment inventories, runs customer jobs and spreadsheets, manages time and is gearing up for mission-critical applications development projects.

If this sounds like MIS type procedures, that's because networks are growing up. They are assuming similar, if not the same, responsibilities. Its time to start dealing with them accordingly.

Blair Preston works for a large financial services company in the Midwest. Previously, he worked with mission-critical networks at EG&G at the Kennedy Space Center in Florida and at Amoco Production Co.
COPYRIGHT 1992 Nelson Publishing
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1992 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Disaster Recovery; computer networks should incorporate certain features to minimize impact of disasters
Author:Preston, Blair
Publication:Communications News
Date:Apr 1, 1992
Previous Article:Key elements in disaster and recovery planning.
Next Article:F-T1 lets Bessemer distribute LANs cheaply.

Related Articles
Disaster recovery in the new decade: retrofit answers will not make it in the '90s.
Who needs a disaster?
How we built our contingency plan.
Protecting million dollar memories.
Disaster proves ironic test for SAN core-systems manufacturer.
Sun Microsystems, Inc.
Vaulting provides disaster relief.
Is your business prepared for disaster? The computer equipment and information critical to your business is most vulnerable to disasters.

Terms of use | Copyright © 2016 Farlex, Inc. | Feedback | For webmasters