Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!uflorida!novavax!proxftl!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: comp.unix.microport
Subject: Re: A better floppy backup (was Re: Corrupted backup floppies from cpio)
Message-ID: <135@twwells.uucp>
Date: 1 Nov 88 19:07:49 GMT
References: <6794@chinet.chi.il.us> <4873@b-tech.ann-arbor.mi.us> <838@philmds.UUCP> <3950@encore.UUCP> <118@twwells.uucp> <4897@b-tech.ann-arbor.mi.us>
Reply-To: bill@twwells.UUCP (T. William Wells)
Organization: None, Ft. Lauderdale
Lines: 76

In article <4897@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
: In article <118@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes:
: >You are so right.  In fact, I haven't seen anything that meets my
: >requirements for floppy backup so I am writing one.
: >
:
: Here are some things I'd like to see in a backup program.  Your program
: evidently has some of them.
:
: 1) True error correction like Fastback.  I can punch a hole in a Fastback
: disk and still get *all* my files back.

It does some of this. The gotcha is that it can't handle two cylinders
corrupted on the same track/sector. I could fix this by adding more
or fancier error correction, but that would take more of the disk
space or my spare time.

: 2) When I back up, I use
:      cd /
:      find . -print | sort > backup.list
:      cpio -ocv < backup.list | ...
:
:    It would be nice if the program created a new list file that had lines
:    "** Disk 2 starts here".  I could then look at the list to tell me what
:    floppy a file is on.

I could make it write additional information under the -v option.
What it does now is to display each file as it is being written; what
it could do is prefix each file with the disk number on which it is
being written. Would that do?

: 4) A verify option that reads back each disk after writing it.

-p for paranoia? :-) I can add that.

: 5) A check for out of sequence floppies.  Let's say I'm backing up and
: the program asks me to put in the next floppy and hit return.  I accidently
: hit return before switching.  Will the program respond "That looks like the
: same disk - continue anyway?".

Even better than that: not only will the program detect out of
sequence floppies, but it is perfectly happy to let you restore from
them. In other words, if you know which floppy the thing is on, you
can just insert that floppy. The program will ask you about it but
will then go on and restore whatever is on the floppy. Of course, if
the last file on a floppy is split across two floppies and you put in
the wrong floppy, you won't get the whole file (though you will get
an error message).

: 6) cpio or tar compatible output would be nice.  We don't need a new
: standard.

That is incompatible with reasonable error recovery, so we get a new
format. Such is the way it goes.

: 7) The ability to seek past errors and continue.  Sometimes when you get an
: error you can't get the raw device to read past it.

It does that.

: 8) Individual file compression (ie, compress each large file before storing
: it vs compressing the whole archive).  Then I lose only one file
: instead of the entire remainder of the archive.

The -c option does it that way.

: I suspect that you can do most of what you want with just a front-end
: for cpio.

I thought about that, with the idea that I would cpio the data and
then run it through a disk I/O program. However, that didn't let me
do things like individual file compression, nor did it make it
reasonable to resynchronize after an error.  Oh well.

---
Bill
{uunet|novavax}!proxftl!twwells!bill