MultiTape Backup

[Jerry LeVan]

Hello,

Here are some of my observations with trying to deal with
multitape backups with the Apple 40 meg tape drive.

My test bed is my X11R4 disk, an 80 meg apple hd80sc with
a maximal Aux partition with no mac partition.

cpio:
        This program evidently cannot deal with multiple tapes

tar:
        tar cvbBf 16 76200 /dev/rmt/tc1 .

        This command started the backup and asked for a second
        tape. Somewhere in the second tape I got a core dump

        tar cvbBf 16 76200 - . | tcb > /dev/rmt/tc1

        The above command seems to fill the first tape ok and
        then asks for a second tape. The first write to the second
        tape always causes an error and the backup aborts.

pax:
        pax -w -b 8k -v -f /dev/rmt/tc1 .

        This command correctly asks for a second tape. (I calculated
        that the backup should take two tapes). The program does not
        appear to terminate cleanly, by this I mean that when the
        backup is complete the program will ask for another tape,
        write nothing and immediately ask for another tape (indefinitely).
        The program took about 2.5 hours to copy 67+ megabytes.

        When I attempted to read the tapes for a table of contents
        I found that I had to use the "dd" command and pipe the
        results into the pax command, here is what I used:

        dd if=/dev/rmt/tc1 ibs=40*8k | pax -v

        This is what happened:
        ...
        ...
        ...
        -rw-r--r--  0 levan    family      11528 Apr 23 16:13 ./src/mit/fonts/bd
f/m
isc/clR8 x13.snf
        -rw-r--r--  0 levan    family      12040 Apr 23 16:14 ./src/mit/fonts/bd
f/m
isc/clR8x14.snf
        pax: - : This doesn't look like a tar archive
        pax: - : Skipping to next file...
        120+1 blocks in
        77248+0 blocks out
        pax: Ready for volume 2
        pax: Type "go" when ready to proceed (or "quit" to abort): go
        pax: [offset 37m+736k+0] Continuing
        pax: Ready for volume 3
        pax: Type "go" when ready to proceed (or "quit" to abort): go
        pax: [offset 37m+736k+0]: Continuing
        pax: Ready for volume 4
        pax: Type "go" when ready to proceed (or "quit" to abort): go
        pax: [offset 37m+736k+0]: Continuing
        pax: Ready for volume 5
        pax: Type "go" when ready to proceed (or "quit" to abort):

        Note that the second tape was not read ( I immediately
        got the request of the third tape, typing go caused the
        next tape to be asked for etc... There does not appear to
        be a way to access the second tape.

        I tried giving the command(with the second tape installed)

        dd if=/dev/rmt/tc1 ibs=40*8k | pax -v
        pax: - : This doesn't look like a tar archive
        pax: - : Skipping to next file...
        -rw-r--r--  0 levan    family      13064 Apr 23 16:14 ./src/mit/fonts/bd
f/m
isc/clR8x16.snf
        ...
        ...
        This seems to pick up properly, examining the directory reveals that the
        "last" file on tape one is in the directory immediately followed by
        the "first" file extracted (OK listed) on the second tape. Maybe
        it is possible to do a multitape restore.

        Is pax and tar smart enough to not split a big file across
        multiple tapes? Or is there some sychronization mechanism
        which allows restoring file split across multiple tapes?

dump.bsd:
        This program has trouble with specifying the size of the
        tape by using the "c" option or any of the explicit size
        settings using a byte count. Apparently one can lie also
        by setting the density and length arguments, here is
        what I used.

        # dump.bsd -T5.2 0bsdf 8k 542 12500 /dev/rmt/tc1 /dev/dsk/c5d0s0

        The above command stopped at the appropriate times and waited
        for fresh tapes. The whole process took a little over an hour
        and wrote 74525 tape blocks on 3 tape(s).

        It is not perfectly clear how tightly the above command
        packs the tapes. (Almost nothing was written on the third
        tape).

        I then reformatted the disk (to a 4.2 file system) and
        attempted a restore via the "restore command". All appears

        to have been properly restored ( I have not tryed
        a "make world" command yet).

Conclusions:
        All of the backup programs appear to be damaged to some
        extent. Dump.bsd appears to be at least twice as fast
        as tar and pax (but I could not get tar to function
        properly for multiple tapes).

        I wish Apple would make available the list of known problems
        (and possible work arounds) for A/UX. How about a section
        on support.aux.apple.com ( or is that aux.support.apple.com)

Appendix:
        I tryed backing up my root partition (92 meg) with ExpressTape v4.1.
        This program failed 3 times with 3 different sets of tapes. Apple's
        HD Backup program WAS able to do the backup.( I have not
        tried a restore...My distribution media was defective and
        Apple loaded A/UX for me, I am starting the seventh week
        of waiting for a replacement). In ExpressTapes defense let
        me add that it did a fine job of a "files" backup of my
        60 meg Mac Partition. Only took a little over an hour to
        do the backup. This is MUCH faster that the Apple Backup
        program in file by file backup.

That's the story the way I see it.

Jerry

-----------------------------------------------------------------------------
| Jerry LeVan                           | Phone:(606)-622-1931              |
| Department of Computer Science        |                                   |
| Eastern Kentucky University           | Email:matlevan at eku.bitnet         |
| Richmond Ky 40475                     |                                   |
|---------------------------------------------------------------------------|
|      "The series converges so slowly that it actually diverges."          |
-----------------------------------------------------------------------------