>Ach!! I am close, I can feel it... I was playing around waiting
>for replies, and I did the following:
>
>mt -f /dev/nst0 rewind
>dd if=/dev/nst0 bs=32k count=1
>dd if=/dev/nst0 bs=32k count=1
>dd if=/dev/nst0 bs=32k count=1

First, you need to realize a couple of things:

  * The system you're on uses BSD tape semantics.  That means when you
    read some blocks, the tape stays positioned in mid-file.  If it used
    SystemV semantics, the tape would auto-fsf to the next file.

  * The "count=1" parameter reads one **block** (record), not one file.

>the first one showed me:
>
>AMANDA: TAPESTART DATE 20010227 TAPE Daily3

Right.  That's the tape label (file 0, block 0).

>the second gave me:
>
>0+0 records in
>0+0 records out

Right.  That's the tape mark (EOF) between the tape label in file 0
and the first backup image.

>and the third produced:
>
>AMANDA: FILE 20010227 backup.diligence.com /pkgs lev 0 comp .gz program 
>/bin/gtar
>...

Right.  That's the block 0 of file 1 which is an Amanda image header.

>when I do:
>
>mt -f /dev/nst0 rewind
>mt -f /dev/nst0 fsf 02

Whoa.  Why "fsf 2"?  That skips to the second **file**.

>I get an I/O error...
>...
>So, then I tried
>...
>I also get an I/O error...
>
>Then I tried to dd the first two to /dev/null

Which is the same as:

  mt -f /dev/nst0 rewind
  mt -f /dev/nst0 fsf 1

>and the third time I do
>
>dd if=/dev/nst0 bs=32k skip=1 | /usr/bin/gzip -dc | bin/gtar -f... -
>
>I see:
>
>dd: /dev/nst0: I/O error

Right.  This all fits.  Block 1 of file 1 is bad and cannot be read.
Period.

>Am I going to need to identify the start and end of this file and do it by 
>count?

No.  You're going to have to fix the tape drive or abandon trying to
get the data back from that tape.  It's broken.

>Jer

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Reply via email to