Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!usc!apple!genbank!ames!ll-xn!vlsi!malpass
From: malpass@vlsi.ll.mit.edu (Don Malpass)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Backups: (was: Formatting 720K disks to 1.44 Megs HELP!!)
Summary: Fastback or Zenith 286 Laptop problem?
Message-ID: <408@vlsi.ll.mit.edu>
Date: 30 Nov 89 14:36:39 GMT
References: <1989Nov27.212809.7241@ux1.cso.uiuc.edu> <1114@bridge2.ESD.3Com.COM> <89Nov28.223437est.19733@me.utoronto.ca>
Reply-To: malpass@ll-vlsi.arpa.UUCP (Don Malpass)
Distribution: na
Organization: MIT Lincoln Laboratory, Lexington MA
Lines: 33

In article <89Nov28.223437est.19733@me.utoronto.ca> yap@me.utoronto.ca (Davin Yap) writes:
>I use Fastback Plus (2.08) to back-up my hard disk, using 720K disks as
>1.44 Meg disks.  I use both the compression and error-correction options.

Fastback-Plus: Have you also used the "Check" or "File Compare" option
(I can't remember the exact name) in the Restore menu on your backup
disks?  I just went through this exercise using HD (not 2D!) disks at
1.44 Megs, and the results were an eye-opener!  This was on a Zenith
286 SuperSport Laptop, which after a call to the Fastback hotline I
also find needs to have the DMA option manually throttled back from the
maximum rate that their test passes.  Anyway, after the backup (and I
called for all the [slow] write-verify options too) I did the file
compare thing, (I was about to reformat my HD and didn't want to take
any chances) and out of the 8Meg or so backed up, it gave a non-compare
message for 5 or 6 files!  So I did a second identical backup.  Again,
several files didn't compare.  Doing a second compare on the same
backups found about the same number of complaints; a few for the same
files, a few new ones.  Clearly something is flakey (strongest evidence
is the floppy drive), and I wonder if anybody else is having such
problems.  My message, however, is: RUN THE COMPARE OPTION AFTER THE
BACKUP!  Sure it takes time, but as has been stated by someone else, if
the backup is bogus, how much good is it.  You KNOW the only file which
gets trashed and needs to be restored will be the only one that is sick
on the backup.  My "solution", by the way, was to print the CRC's
(Unix-SUM, actually) of all the files that didn't compare and then
re-restore from one of the two backup sets any that looked bad after
the format/restore had been done.  I'll probably save BOTH backup sets
for the future.  Has anybody else experienced similar problems?

-- 
Don Malpass   [malpass@LL-vlsi.arpa],  [malpass@gandalf.LL.mit.edu]
   ... A concerned and somewhat ashamed member of the only species
      which DESERVES extinction, Homo sapiens.  11/89