amrecover failure, corrupted gzip file?

Hi --

Running Amanda 2.4.4 servers and clients, using a RedHat 7.3 tape 
host, backing up using DUMP method (dump/restore) ext2 filesystems on 
a RedHat 7.2 client host:

I tried to do an amrecover on the /home filesystem (~8 GB), which
recovered all of the directories (as expected) and about 2/3's of the
actual data before terminating with a message asking if I wanted to 
change volumes (which I stupidly forgot to cut and paste, and can't 
find in any of my scrollback buffers, sorry).  Then prompted for 
aborting, then whether or not to dump core, the terminated.  Nothing 
particularly unusual in the amrecover debug file on the client side.

The corresponding amidxtaped debug file on the tape host side seemed 
to be running normally, then terminating on a gzip error:

  amidxtaped: time 10.959: Ready to execv amrestore with:
  path = /usr/local/sbin/amrestore
  argv[0] = "amrestore"
  argv[1] = "-p"
  argv[2] = "-h"
  argv[3] = "-l"
  argv[4] = "LSX-13"
  argv[5] = "-f"
  argv[6] = "2"
  argv[7] = "/dev/tapex"
  argv[8] = "^whisper$"
  argv[9] = "^/home$"
  argv[10] = "20030315"
  amrestore:   2: restoring whisper._home.20030315.0

  gzip: stdin: invalid compressed data--format violated
  Error 32 (Broken pipe) offset -2147483648+131072, wrote 0
  amrestore: pipe reader has quit in middle of file.
  amidxtaped: time 3606.244: amrestore terminated normally with status: 2
  amidxtaped: time 3606.244: rewinding tape ...
  amidxtaped: time 3623.767: done
  amidxtaped: time 3623.768: pid 5140 finish time Thu Mar 20 11:11:19 2003

I was able to recover the raw file from tape using dd, i.e.

  dd if=/dev/tapex of=./label-x bs=128k count=1

which recovered:

  AMANDA: TAPESTART DATE 20030315 TAPE LSX-13

Then:

  mt -f /dev/tapex asf 2
  dd if=/dev/tapex of=./label-2 bs=128k count=1

which recovered:

  AMANDA: FILE 20030315 whisper /home lev 0 comp .gz program /sbin/dump
  To restore, position tape at start of file and run:
          dd if=<tape> bs=128k skip=1 | /usr/bin/gzip -dc | sbin/restore -f... -

I did that, and was successful in recovering the file from tape:

  -rw-r--r--    1 msimpson msimpson 2872049664 Mar 20 13:20 whisper_home_0.gz

I tried to do the pipe to "restore", with a failure similar to the 
above.  The gzip file looks like it's become corrupted:

  $ file whisper_home_0.gz
  whisper_home_0.gz: gzip compressed data, from Unix, max speed

  $ file -z whisper_home_0.gz
  whisper_home_0.gz: new-fs dump file (little endian), This dump Sat Mar 15 
20:03:59 2003, Previous dump Wed Dec 31 18:00:00 1969, Volume 1, Level zero, 
type: tape header, Label none, Filesystem /home, Device /dev/datavg/homelv, 
Host whisper.doit.wisc.edu, Flags 1 (gzip compressed data, from Unix, max speed)

_but_:

  $ gzip -l /projects/archives/whisper_home_0.gz
    compressed        uncompressed  ratio uncompressed_name
    2872049664                   0   0.0% whisper_home_0

and when I try to unzip it, even using the trick I found at 
www.gzip.org to avoid the 4gb file limit that's apparently a problem 
on some versions of gzip, I get the same error as in the debug file:

  $ gunzip < whisper_home_0.gz > whisper_home_0

  gunzip: stdin: invalid compressed data--format violated

  $ ls -l whisper_home*
  -rw-r--r--    1 msimpson msimpson 2872049664 Mar 20 13:20 whisper_home_0.gz
  -rw-r--r--    1 msimpson msimpson 6030524416 Mar 20 15:23 whisper_home_0

Any tips or tricks or other thoughts?  Is this the Linux dump/restore 
problem I've seen talked about on the mailing list?  I don't 
understand how the gzip file could be corrupted by a problem internal 
to the dump/restore cycle.

Thanks for any help,

-mgs