Notes from the KLUG meeting of 27-DEC-1997

["Robert G. Brown" <bob@xxxxxxx>]

The meeting came to some semblance of order about 3:20 PM, with about 10
people in attendance altogether. 

Again, we had a choice of presentations - I stepped forward to discuss
the recent loss of a hard rive, and what's been done to recover from it.
Bruce Smith had prepared a talk on hard disk management.

Given the choice and attendance, we seemed to opt for the less formal talk,
my recent "disaster".

Background
==========
  Readers of this mailing list may recall that I distributed a message on
Christmas afternoon in regard to a hard disk failure (the drive had actually 
failed the previous day).  I've been doing regular backups with the LINUX
ftape (3.01) driver, the tar utility on an Iomega 3200 tape drive, connected 
to the floppy disk controller.

 Brief Summary:
    The version of ftape that is shipped with RH Linux is rather old, and does
not support the tape drive well. In September I downloaded a much newer and im-
proved version, compiled and installed it, and have been using it since.

    The key error I made was not saving the newer ftape driver on something
other than tape itself! When the hard drive failed and a replacement was ob-
tained, several steps had to be taken before restoration of any files could
be attempted:

  - Linux had to be re-installed. This would have been true in any case,
    but it's possible that a very small install would be needed if a better
    restoration plan had been in place.  Actually, a good restoration method
    would have included a very small version of Linux.

  - The kernel has floppy tape support -- for the old driver! It has to be
    removed, and that requires a rebuild (recompile) of the kernel.

  - The new version has to be located on the net and downloaded. This means
    that the new Linux system has to be configured to run over the INTERNET
    (isn't all that reconfiguring one of the reasons we do backups?). I was
    lucky here, I had saved these files on a floppy diskette, and restoring
    them put me online in a few minutes.

  - The new driver (I got a NEWER version, 3.04d of ftape) now has to be con-
    figured, compiled and tested.

Note that one must take all of these steps without knowing if the tape will
be useful!  I was concerned that the newer ftape would no longer support the
tape format, or that understanding it would be harder.  These worries could 
not change what had to be sone, and There were two difficulties encountered 
along the way:
   
   - There seemed to be a problem in compiling the kernel!  This was the topic
     of a message to the mailing list late on Christmas afternoon. Bruce Smith
     was quite kind in compiling a 2.0.32 kernel and emailing it to me, but
     it proved incompatible with my 2.0.30 modules and so forth. Eventually,
     I was able to compile, and proceeded from that point.

   - I had backups of all sizes, but it seems that the larger backups could 
     not be restored. My largest error-free restore was 78 Mb in size, and it
     was simply impossible to extract useful data from archives over 100 Mb
     in size.  Fortunately, almost everything that was in those very large 
     archives had been downloaded or loaded from CD-ROM. It did take 2 even-
     ings of intensive downloading to recover everything lost, and not all
     of this software has been installed yet.

Despite all the problems, having backups was far better than NOT HAVING any
backups. Without backup, it would have taken several weeks to rebuild every-
thing, and it would have been much more difficult to return to a useful sys-
tem than it turned out to be.

Now, what did I learn?  What are my future plans?

    - Build a diskette set with the correct ftape driver and kernel.
      Instead of install, recompile, download, compile,test, restore.
      The set I have in mind is just enough of a system to restore from 
      tape.  It's not enough to have backed up the data; one must make
      sure that the restoration process can start from a "clean" system
      and proceed smoothly.

    - Use smaller archives. This experience shows that if the size of a
      particular backups is kept small (eg, under 30 Mb) it is less likely 
      to have problems.  By the same reasoning, one may want to keep TWO or
      more copies of each backup.  That way, it one is no good, the other
      may be fine. 

    - Investigate other media for data backup.  One notion that comes to 
      mind is writing CDs, which are archival (write one, save "forever")
      storage. Another is DAT backup instead of floppy-controller tapes
      (see below).

I answered a few questions, the answers to which can be found above (these
notes are somewhat better organized than my informal talk).

-	-	-	-	-	-	-	-	-	-

Then Bruce Smith took the floor, mostly to present an alternate view of backups.

He uses 4mm DAT, and he has never had the restorations problem I reported. A
backup, according to Bruce can be routinely done in on the order of Gigabytes
without error, and both writing and reading tapes is fairly fast. Overall, the 
whole system sounded a lot more reliable than my experience, with a tape drive
that connect to the floppy controller.

The speed and reliability allow Bruce to make much more frequent backups,
which naturally will allow better and more complete recovery in the event of
hardware failure.

One drawback of this approach, Bruce admits, is cost. These tape drives are 
SCSI devices (if you are not using a SCSI system, you'll require a SCSI
controller), and the tape drives themselves cost on the order of about $500.
Tapes, however, are cheap (tapes for my Iomega cost $22).

Bruce counters these problems with 3 points:

   - You're only getting one tape drive, but many tapes. Since 4mm DAT is 
     about 1/4 the cost per Gb, you;re not going to spend nearly as much on
     tapes, and that should be counted toward decreasing the difference in 
     price.

   - Bruce prefers having an all-SCSI system, so the additional cost of a 
     SCSI controller is, in his view, zero.

   - What's your data worth? Perhaps making sure that you can restore anything
     and anything is worth the difference in price, along with the notion that
     you don't need to do anything to break up archives into small chunks as
     Bob suggests.

Bruce answered several questions (also fairly well contained in the above 
notes).

He did not address driving software, but there's plenty of SCSI tape software
drivers out there. 

Several other topics came up that were of interest:

   - Integrated motherboards.  We're against them! 
     I prefer a passive-backplane system, and told stories about the 
     redundant "Stratus" computers, that never go down. Steve Scherbinski
     pointed out that FOA uses Stratus machines for their ATM network.

     Bruce Smith related stories about the IDE controllers that would not
     completely go away, interfering with other devices, and so on.

   - Our web site. Mike List was not available to comment on progress. Is
     there any?

-	-	-	-	-	-	-	-	-	-

This is my last time filling in as minute-writer. I apologize for not getting
this out sooner, but other concerns, as well as the New Year holiday have ta-
ken precedence. If/When Matt returns, his continued contribution will be very
helpful, but if he does not or cannot, would someone step up and perform this
service?  Thank You!

-	-	-	-	-	-	-	-	-	-

                                   THIS SUNDAY
                                3 PM at Cyber-Tek
                                 INSTALLING LINUX

I will Install Red Hat Linux (4.2) and discuss a number of issues related to 
packaging software for distribution. Other distributions have other means of
delivery.  Feel free to come and discuss the method your favorite distribution
uses!