Backup, Or Else

BACKUP, OR ELSE

by Wayne M. Krakau - Chicago Computer Guide, June 1997

As I write this column I am in the middle of a project to attempt to recover data for a client who’s hard drive on a specialty workstation drive crashed, but who had no recent backup tapes. Actually, their hard drive didn’t just crash. It MELTED! The plastic gasket that helped seal the insides of the drive oozed out and dripped sticky goo all over my fingers.

The people at Ontrack Data Recovery (800-872-2599) later told me that this was the first melted drive they had ever seen. They suspect that a broken part rubbed against the spinning platters of the disk and the ensuing friction generated enough heat to turn most of the drive into mush. Naturally, no data was salvaged. Remember this drive the next time someone mentions the reliability of modern computer systems as an argument to lower their standards on backing up data.

This incident illustrates the difficulty of convincing nontechnical people who have never experienced a major computer disaster that they should take extraordinary steps, if necessary, to protect their data. In this situation, I feel partly responsible (and have made a major downward adjustment in my billable hours accordingly), since I didn’t get tough and offer an ultimatum to the client. (Something like "Back up or I won’t deal with you again.") I guess I’m just too soft-hearted to be that nasty.

I was lulled into a false sense of security by the fact that this client was quite cooperative in backing up their file server. When they replied positively to questions about regularly backing up their specialty system, I ASSUMED that they used the same definition of "regularly" that I did. A lesson learned: Never ASSUME that a techie talking to a non-techie is speaking the same language! (Obviously, assuming anything is dangerous.)

Since the backup of their file server was mostly automatable, and the backup of their specialty system was not (due to the space limitations of their backup tapes), the specialty backup was given a lower priority. It tied up a valuable computer for several hours during the day and was somewhat complicated to as well.

Just as I was about to sell them a new tape system with much more capacity and more sophisticated, easy-to-use software, the meltdown occurred. Luckily, all of the data will be recoverable from an auxiliary database that is on removable optical disks, but only after a major, time-consuming and expensive process.

If this was the only incidence of problems with backup plans, I probably wouldn’t have been inspired to write on this subject. Sadly, at least one-third of all the prospects I meet have major inadequacies in their backup systems. Some of these problems are procedural, some are software-related, and some are hardware related. Since software and hardware difficulties should be detected by a proper methodology, I suppose that you could chalk them all up as procedural if you wanted to get picky about such things.

These days, there are many options for backup systems. Tapes are inexpensive when compared to data-recovery fees. More tapes mean more safety IF and only IF they are used in an organized manner. (Notice that I didn’t say "planned", I said "used"!)

For hardware, there are a variety of choices. Travan-4 tape drives can hold up to 8GB (gigabytes) very inexpensively. DDS-3 DAT drives now hold 24GB. 8mm tape drives hold up to 40GB. Finally, for those who want serious data storage, DLT drives hold an amazing 70GB!

If that’s not enough for you, try getting an auto-changer (a high-tech juke box). While not all of the technologies I’ve mentioned have auto-changers available for their highest capacities, manufacturers usually catch up over time. For instance, 24-tape auto-changers have been available for some time for the older 8GB DDS-2 DAT drives. I’m sure that some bright manufacturer is working, even now, on putting a 24GB DDS-3 drive in those changers.

Because of the problems inherent in backing up databases while they are in use, you may feel that you have to compromise your backup process. If your backup process takes so long it overlaps into normal working hours, or your staff works around the clock (hopefully with multiple shifts), you have a problem that used to be critical. Now, all you have to do is get Open File Manager from St. Bernard Software (800-ST-BERNARD). It is an NLM (NetWare Loadable Module) that runs on your file server. It allows live files to be backed up accurately by freezing the file and saving ongoing updates while the backup takes place. After the backup software goes on to the next file, the stored updates are applied. Once the software is set up properly, it is all automatic and transparent to the users of the network.

Finally, there is the matter of the backup software. Server-based software is the only way to go with NetWare 4.x. I prefer to use Backup Exec from Seagate Software (800-234-3793) and have had much more success with their products than any others my clients have used, but I know that others have different preferences.

A key fact is that workstation-based software can’t back up the NDS (Novell Directory Services). Several manufacturers profess to, but, so far, their tech support personnel could not answer my questions well enough to give me confidence in their claims. Senior Novell support staff members have confirmed the inability to back up the NDS from a workstation.

Even based on the chance that some company figures out a proprietary method for backing up the NDS from a workstation, you would be stuck using a method that was not officially approved by Novell. In that case, just try to get serious technical support from Novell while you are rebuilding a server after a major crash!

If you are stuck using an existing workstation-based backup solution, then you can download a program called DSMAINT from the Web. This is an NLM that does Directory Service Maintenance. One trick it can do is to back up and restore the NDS onto a floppy or some other disk drive.

With all users logged out, you execute a procedure which shuts down the NDS. Then you do the actual backup. This only takes a couple of minutes. Then you reawaken the NDS. Finally you bring the server down and bring it up again.

If, like me, you don’t read the directions as thoroughly as you should before trying DSMAINT the first time, you can set yourself up for quite a scare. I thought that I could just do the down and up sequence after the backup. I believed that this alone would reenable the NDS. WRONG! All that does is generate dozens of nasty messages which seem to indicate that you have permanently lost or at least critically damaged the NDS.

I think I gained multiple gray hairs from that stunt. Loading DSMAINT, reenabling the NDS, and doing another down and up sequence fixed the self-generated problem. (So much for the ace systems integrator!)

It is important that you remember to do another DSMAINT NDS backup any time you alter the NDS. If you change anything in NWADMIN or NETADMIN (the Windows and DOS administration tools for NetWare 4.x), you have altered the NDS. This is also true if you add, delete, or modify any program that directly affects the NDS. If in doubt, then run another backup. Scheduling regular DSMAINT NDS backups is an even better idea. As a manual task that can only be done when nobody is logged in, this might seem inconvenient, but it is not as convenient as being without a current copy of your NDS tree after a crash.

As I write this article, new, lower unemployment figures are being reported. If you don’t want to make your own personal dent in those statistics, then I suggest you make sure your backup system - hardware, software, plans, and especially the execution of those plans - really works.

Š1997, Wayne M. Krakau