On Wed, Apr 07, 2004 at 02:44:10PM -0700, Dege, Robert C. wrote:
> thanks for all this info.  I am able to run these dd commands successfully.
> So I'm beginning to think that amanda is the source of the problem.

Here's a stab-in-the-dark sort of guess: maybe amrecover is using
a different gtar than amdump did, and the former can't read the
latter's tarballs.  This:
    tar: Archive contains obsolescent base-64 headers
suggests a format incompatibility rather than data corruption
(though of course, if the latter were just so, it could
masquerade as the former).  If you have an strace, trace, or
truss command (they're all pretty much equivalent), it can help
you determine this.

Which gtar version?  1.13 is known not to work with Amanda
(though the typical symptoms are different from yours); 1.13.25,
from alpha.gnu.org, is recommended.  (There are later versions,
1.13.9x, but I've seen those recommended *against* on this list.
I don't know whether that's because they're known to be broken,
or simply not yet known to be reliable.)

Another thing to try would be amrestore (as opposed to
amrecover).  That pulls backup images off the tape, and
optionally decompresses them, but does *not* try to untar them.
Thus, it would help you to narrow down the problem.  I *think*
the command would be something like this (I use it rarely enough
that I always have to try a few times to get it right):
    $ amrestore [-r] /dev/nst0 hostname DLEname

That will search the tape for the backup of (hostname,DLEname),
pull the entire backup image off the tape, and store it in the
current directory.  With -r, it will store exactly what this "dd"
command of Jay's would have stored:
    dd < /dev/nst0 > tapeimage.1 bs=32k

Without -r, it will strip off the 32-KB header and decompress the
rest, rather like this dd command:
    dd < tapeimage.n bs=32k skip=1 | gunzip
(this is one of Jay's commands too, except that the original had
"| gtar tvf -" appended).

So try this to narrow it down:
 1. pick a restore that you've seen fail
 2. use "dd" and see if that can pull the file off the tape
    without errors (you've already done this)
 3. use "amrestore -r" and see if the output is identical to
    that of (2)
 4. manually header-strip and decompress the result of (2), using
    the second "dd" command above
 5. use amrestore with no -r, and see if its output is identical
    to the output of (4)
 6. For paranoia's sake, try again the same amrecover command
    that failed before.  Unless it fails with the *identical*
    message (except for timestamps, process IDs, and the like),
    and produces *identical* partial restore output, strongly
    suspect hardware problems

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        erics AT telepres DOT com
|  |  /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
        - Patrick Lenneau