LAN Design, Part Three

LAN DESIGN - Part 3

by Wayne M. Krakau - Chicago Computer Guide, December 1994 - NewsWare, June 1996

This article is a continuation of the continuing saga Network Design. Last month I covered fault tolerance, and electrical protection. This month I will begin with backup strategies.

First, plan a reliable pattern of backups. This sounds simplistic, but in many cases it's not being done. I regularly encounter cases of people religiously following a prescribed backup schedule without having a valid backup.

Three way rotating backups with one of the three groups kept offsite is the minimum needed for a reliable system. A simple example of this is a pattern consisting of three weekly sets (Monday through Friday for most businesses) and three of what I usually call "fiscal month" tapes. Each weekly set is used in turn, with one set always kept off site. The fiscal month tapes are also used in turn, every three weeks. While some people think this 18-tape strategy is overkill, even this pattern is something that many mainframe and minicomputer people would sneer at. They are used to much stricter and more thorough patterns. On those systems, mission critical (Don't you just love dramatic-sounding buzzwords?) data is backed up between the individual steps of a given processing task!

(For those of you who may nitpick about my use of the phrase "data is" instead of "data are", please remember that English is a dynamic language, changing to accommodate common usage. Common usage for over 30 years has put "data" in the same category as "herd" and "flock" when used in this context in spite of its Latin roots. In some circles, it is considered an affectation to say "data are" when referring to computer data in this way!)

The second backup consideration is to make sure that you have an appropriate physical backup method. This usually means some type of tape system with a capacity as large as your largest single volume. What's that you say? You can't afford a device big enough to back up your giant disk system? Try this one. An 8GB DAT drive at an approximate street price of under $2100! The tapes cost about $36 each due to the current shortage, but that should drop substantially when the shortage abates. As a bonus, the compression routine is in hardware, not software, so it doesn't revert to half-size (4GB) drive when you attach it to a file server. What's that? You say you say that's not big enough? Try a six-tape autoloader based on the same drive for a street price of around $3600! It even fits in a five and a quarter inch full-height drive bay! There are also much larger specialty systems, including 12-tape and 24-tape autoloaders in the same family. Great bargains are available for smaller systems. No matter what your backup needs, there is an affordable means of reliably backing it up. Realistically, if you can afford 48GB of hard disk space, buying something like this 6-tape autoloader shouldn't be a big problem.

Third, as Nike says in their ads, "JUST DO IT!" Designing a backup system and the logic behind it is useless if the pattern chosen isn't followed. Make it easy to do. Server-based backups can be executed without intervention. For workstation-based backups, assign supervisory rights to a dummy user ID with no password. Restrict that ID to the physical workstation that has the tape. Alter the system login script to automatically turn BREAK off. Execute the backup. Do a verify (also called a compare). Print the results. Use DIR>TEMP1.FIL and DIR TEMP1.FIL to provide time and date stamps both before and after the actual backup. Logout, and then immediately reboot (via the public domain WARMBOOT command) to avoid any possible security problems. If possible, tie the special dummy user ID into the system's automated backup capabilities. If the process is not fully automatable, make sure that the last one out the door logs in under that ID. Obviously, make sure that someone reviews the results and replaces the tape the next business day.

Communications needs are next. At minimum you need a modem and a remote control program on the administrator's workstation. If you use Windows, obviously, Windows capabilities are required to match the resolution that you use. With this system, when you call for help, you don't have to wait for someone to get to your site, or even to laboriously talk through the problem and its solution over the phone. I had enough of that nonsense when I was beating on mainframes! There is no excuse for it, these days.

Just connect with the remote control program, demonstrate the problem, and then sit back and watch it being fixed. In the worst case, at least the appropriate support person can be sent out with exactly the right tools to fix the problem. The dollar savings on the first call alone can often cover the cost of the modem and the software.

The next step is workstation-to-workstation remote control. From your desk you can support your users and install or upgrade software. In larger sites this is a great time-saver. It also impresses the users - a great help in the political environment that surrounds LANs. If the modem software is either the same brand as the workstation software or at least is compatible with it, a support person can take over the administrator's workstation via modem and then take over any workstation on the LAN to help an individual user. This works well in a multi-site installation. The administrator can call another site and provide support right to the desktop. Note that Netware's RCONSOLE, the program that allows supervisory personnel to take over the main console from a workstation in Netware 3.x and 4.x networks, is compatible with remote control software. For those of you that have specialized communications servers running Netware Connect or one of its competitors, you can get remote control software that will run via your communications server.

Tune in next month for the final (at last) episode of LAN Design and find out if the intrepid systems integrator is felled by the evil Bugmaster!

Š1994 Wayne M. Krakau