This is getting ridiculous! I'm now getting at least one new client per month who is backing up its data in what turns out to be an invalid or inconsistent manner. A false sense of security keeps these system managers (if you run a LAN or even a single computer, you're THE System Manager even if you're a "civilian" and don't use the title) thinking that they are doing their duty and safeguarding their computer systems (mostly LANs). In reality, they were really running either partially or fully unprotected.

One client had been using the same five 60MB (Note: MB=Megabyte, Mb=megabit) cassette-style tapes since 1986 to back up a 102MB network hard disk that held 97 MB! This is the proverbial ten pounds of potatoes in a five pound sack.

The dealer who sold them the system thoughtfully automated the backup process with a batch file. He (I know it's a guy - I asked) was so considerate, in fact, that he disabled the ability to automatically request continuation onto a second tape when the first was full. None of that time wasting stuff for his customers. No more of those annoying, error messages, either -- he suppressed displaying them. And knowledge of the error log file really should be on a need to know basis, so don't tell anyone about it, and certainly don't do anything radical like printing it out at the end of the backup. As for the verify (also called compare) function, well, that's like having a belt and suspenders. Let's skip it. Finally, the most confidential aspect of a backup system is the backup software itself. This, of course, means that you shouldn't reveal where it is hidden, and you absolutely can't divulge the ultimate of secrets -- how to execute it manually in an emergency.

While we're on a roll, let's also skip the lesson on multiple redundant backup tapes. Tapes won't ever wear out or get damaged. Besides, what's the few cents profit per additional tape sold versus the potential income in reconstructing a blown database. A side benefit is that you can also underbid the competition by including just a few tapes in your bid. And, again, keeping profit in mind, don't warn the customer about the effects of smoke and dust around a tape drive. Just wait for those lucrative repair calls. No lesson on retensioning or reformatting either -- time-wasters all!

The interesting thing about this is that the clients didn't even know that they were in trouble. They surely didn't know that critical portions of their main database, the one that the business depends on, were not included on their backups! They religiously followed the directions that they had, so no one could say it was their fault.

Through sheer luck, no catastrophe ever required the use of their backup tapes. Those tapes were completely worn out and could barely sustain the data that did fit on them. I outfitted them with a 250MB (to allow for planned expansion) DC2000 style tape drive (a Colorado Memory Systems Jumbo 250) and a controller with hardware compression (Colorado's TC-15). With a little added RAM (random access memory) and a memory management program (QuarterDeck's QEMM), this system could do a complete (really complete, this time) backup and verify in less time than the old tape drive could do its aborted backup without verifying.

This client now uses 18 tapes. The time it took to explain to him why the tapes were needed (and to get his eyes to pop back into his head) ate up more money than the minuscule profit on those tapes. He agreed with the backup/disaster recovery plan that I proposed. Actually, it's a modified version of a quite common one, devised on mainframe systems many years ago when the big iron folks (yes, I was one) first started to look upon computing as a potentially disciplined science, and not as an art (well, maybe a craft).

In this clients new system, there were three main sets of tapes, each consisting of a Monday, Tuesday, Wednesday, and Thursday modified backup (only new or changed files are backed up), and a Friday full backup. The active set is kept in a hallway adjacent to the room where the computer with the tape drive resided. The secondary set (from the previous week) is kept in the opposite side of the building, a considerable distance and several walls away from the first set. The final set (from two weeks ago) is taken offsite. In this case an actual vault would have been overkill, so the system manager just takes the tapes home. The other group of three tapes is a sort of fiscal monthly set. At the end of each three-week cycle (this client's fiscal month for backup purposes), a full backup is made and immediately taken offsite.

I have had several other clients running into the capacity problem (too much data for their backup system), one with a Bernoulli Box (from Iomega) on a single-user system, and the rest with tape drives on LANs. In each case, the system manager (again, all civilians) didn't realize that only part of the data was being saved.

By far the most common problem that I see is the use of too few tapes, or a poorly planned pattern of use. While not everyone needs to be as thorough as the client that I mentioned, the use of one, three, or even five tapes just doesn't make a system safe. It’s very common to discover an error in a major database, examine your backups, and find that the problem actually occurred some time ago.

Another client of mine had problems with their main (and vital) database. The error that caused the data corruption had occurred three weeks prior to their noticing the problem. Sadly, they thought that it was better to make a full backup every night and reuse the same six (they worked on Saturdays) tapes every week than to follow the agreed upon backup plan. The "extra" tapes were held in reserve since their tapes had an unusually high failure rate (later determined to be due to damage caused by smoke - they eventually declared a nonsmoking policy because they got tired of paying repair and replacement bills on computers -- final tally: two keyboards, a power supply, and a motherboard dead, plus numerous repair calls, all from obvious smoking related problems -- they haven't made a hardware service call since the policy change). They had been fed bad information from the corporate MIS (that's Management Information Systems) department, but I still feel partially responsible since it was my duty to impress upon them the importance of sticking to the backup plan.

With no regular backup from an appropriate period, we had to go back to the last yearly tape (this was in March). We were lucky, since that tape had been put in the "extra" bin but had not yet been reused. The client had to have some of the data reconstructed by the software vendor (they used a vertical market package from a very small vendor who used a proprietary file format that they would not reveal -- if you wanted to reconstruct data, export it to a spreadsheet for further analysis, or even needed a simple report, you had to purchase their custom programming services -- the vendor was expensive, slow, and not particularly competent). The rest of the data had to be manually reentered from the original input forms and some transaction reports. This client immediately reinstituted the original backup procedures with some enhancements to make it even more thorough. It only takes one incident like that to "get religion".

NOVELL NEWS: Due to an outcry from existing Netware 2.2 users, Novell has partially recanted their statements regarding the impending obsolescence of Netware 2.2. They now say that it will be further enhanced with management and other features, but are still non-committal about a possible 2.3 version. It sounds like there will be a few improvements, but not enough to warrant a major version number alteration. Since most vendors providing Netware enhancements are still treating 2.2 as a second-banana at best (as per last month's column), my advice is still to stick with (or move to) Netware 3.11. It is the future.

As always, questions, comments, and topic suggestions are always welcome.