bill@twwells.uucp (T. William Wells) (10/25/88)
In article <3950@encore.UUCP> bzs@xenna (Barry Shein) writes:
:
: The problem is that cpio is not a backup utility and it's
: irresponsible to use it as such.
You are so right. In fact, I haven't seen anything that meets my
requirements for floppy backup so I am writing one.
I am looking for people to help me test this thing. Since it is going
to be my primary backup, I want it bashed on as much as possible
before commiting to it. Anyone who is interested should send me
E-mail at the address in my signature. This thing is being written on
a Zenith 386 under the latest Microport UNIX; if you are using a
different system, you may need to do some porting. I will try to
make this program as general as possible, and to maintain any
reasonable ports.
Following is a longish description of the program; if you have any
comments or suggestions, feel free to send them along. These should
probably be posted, rather than E-mailed, as a debate on their merits
would probably be useful.
---
The program `fbackup' takes several arguments. First, it must have
one of `brl', for backup, restore, or list. It may also have a `v'
argument to cause it to write additional information as it processes.
The output devices are specified with -d options and there may be
more than one of them. They must be raw floppy disks, and the
program checks for this. If you don't specify any output devices,
there is a default. The program pauses before writing to the first
output disk specified; it is up to the user to make sure that the
other drives are filled before the program gets to them.
Informational messages are written to standard out, error messages
are written to standard error, and instructions and queries relating
to the floppies are written to /dev/tty.
---
fbackup -b[fcv] [-n name] [-d device]...
Backup each file whose name is read from standard in. The backup
specific options are:
-c Compress the data as it is being written. This saves space,
but does make retrieving data in a damaged file impossible past
the point of damage.
-f Format each floppy before writing to it. If an I/O error
occurs while writing the floppy, Fbackup will attempt to
reformat the bad disk; however, if your disks are known to be
unformatted, this will save time.
-n Specify a name for the backup. This name, along with the
current date is stored on each floppy of the backup.
The program refuses to use a floppy disk which has any bad sectors.
Should it be unable to write the floppy disk, you will just have to
replace the disk with a new one.
Different versions of the program might write different format
backups; however, the backup format is designed so that newer
versions of the program can always read older backups.
---
fbackup -r[auv] [-n name] [-d device]... [files]...
Restore files from floppy disks. If no files are specified on the
command line, all files on the disks are restored. If a directory
name is specified, all files under that directory are restored.
When directories are restored, should there be files in the directory
which are not noted in the backup, warnings will be printed. Special
files can be restored, though normal permission restrictions apply.
Restoring will attempt to preserve as much information as it can.
This includes the user and group names, access times, and file modes.
Files which were linked when backed up and restored at the same time
will have the links recreated, if possible. The backup stores the
user and group names, not the user and group ids, these are
translated back when the files are restored.
-a Normally, leading slashes in the backed up file names are
ignored, causing restores to be done relative to the current
directory. If this is undesirable, specifying -a causes the
restore to be done honoring absolute path names.
-n If this option is specified, the backup name on the disk is
checked against the argument.
-u Normally, the restore will not replace a file with an older
version from the backup; the -u option will override this,
causing the files to be restored regardless of the relative
modification times.
The program is very tolerant. If there is an error reading data from
the disk, it will attempt to recover the error from the checksum
information. If a file is damaged, it will attempt to restore as much
of the file as possible. Even if a file is damaged, it will go on to
the next file. Since sequence numbers are maintained in the backup,
even if entire files are lost, you will be informed of how many are
gone.
Moreover, the program deals fairly reasonably with disks inserted in
the wrong order. Should you know that the files you want are on disk
three of the backup, you can just insert disk three. You will get a
warning, but the files will be restored anyway.
---
fbackup -l[v] [-n name] [-d device]...
List the files on the disks. Without the -v option, just the names
are listed. With the -v option, the files are listed as if with an
ls -il.
---
Bill
{uunet|novavax}!proxftl!twwells!billzeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (10/27/88)
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. 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. 4) A verify option that reads back each disk after writing it. 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?". 6) cpio or tar compatible output would be nice. We don't need a new standard. 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. 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. I suspect that you can do most of what you want with just a front-end for cpio. -- Jon Zeeff Ann Arbor, MI umix!b-tech!zeeff zeeff@b-tech.ann-arbor.mi.us
bill@twwells.uucp (T. William Wells) (11/02/88)
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