Hi,
on Wednesday 29 December 2004 16:29, Brian Cuttler wrote:

>>Amanda    2.4.4p1-20030716
>>SGI/IRIX  6.5.19m
>>mtx       1.3.8
>>8 Slot jukebox with SDLT 320 (Quantum)
>>gnutar    1.13.25
>>
>>I suppose this configuration looks familiar to some of you.
>>
>>I was in the process of writing an email to thank Stefan Weichinger,
>>Gene Heskett and Eric Siegerman for the terrific and patient help
>> they gave me with my new amanda config.

Welcome ;-)

>>I am able to "see" the DLEs on tape but I'm unable to retried any
>> data, either from the dump or the tar partitions.
>>
>>samar 144# mt -f /dev/sdlt2 rewind
>>samar 145# /usr/local/sbin/amrestore /dev/sdlt2 samar /usr5/dtaylor
>>amrestore:   0: skipping start of tape: date 20041227 label SAMAR23
>>amrestore:   1: skipping samar._usr1.20041227.1
>>amrestore:   2: skipping samar._usr5_lalor.20041227.1
>>amrestore:   3: skipping samar._usr5_amanda.20041227.0
>>amrestore:   4: restoring samar._usr5_dtaylor.20041227.1
>>amrestore: read error: I/O error
>>
>>gzip: stdin: unexpected end of file

And you don't get a file with this command?
I once had this behavior on one of my machines, just have to remember
...

You could also try to specify the blocksize with the amrestore-option
"-b", maybe this is not detected correctly.

Do you use DUMP or TAR for samar._usr5_dtaylor?

>>I am able to use amrestore with the "-r" option which results in
>>files like this
>>
>>
>>samar 77# more samar._usr5_lalor.20041227.1
>>AMANDA: FILE 20041227 samar /usr5/lalor lev 1 comp .gz program
>> /usr/local/sbin/gnutar To restore, position tape at start of file
>> and run:
>>        dd if=<tape> bs=32k skip=1 | /usr/sbin/gzip -dc |
>> usr/local/sbin/gnutar -f... -
>>
>>
>>where the rest of the file is empty.

Tried this with one of my holdingdisk-chunks, the "rest" is not empty
here.

>> I should be more explicite.
>>
>>samar 82# ls -las samar._usr5_lalor.20041227.1
>>  64 -rw-r-----   1 root sys 32768 Dec 29 15:36
>> samar._usr5_lalor.20041227.1

This one is only 32768 kB in size ... a header.

>>
>>samar 79# cat -evt samar._usr5_lalor.20041227.1 | head
>>AMANDA: FILE 20041227 samar /usr5/lalor lev 1 comp .gz program
>> /usr/local/sbin/g nutar$
>>To restore, position tape at start of file and run:$
>>^Idd if=<tape> bs=32k skip=1 | /usr/sbin/gzip -dc |
>> usr/local/sbin/gnutar -f... -$
>>^L$
>>^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
>>^@^@
>> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
>>@^@^@
>> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
>>@^@^@
>> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
>>@^@^@
>>
>>The file headers are there, I just don't know where the data has
>> gotten to. I certainly see multiple "chunksize" files in the work
>> area when I'm running amdump.

Are the chunks still there? This would explain why the headers have
made it to the tape, while the data (or parts of it) is still in the
holdingdisk. (This is also a lev1-dump, so the question is, if there
were any changes at all?)

What did the REPORT-mail say?

>>I've otherwise tested the tape drive with the native version of #
>> tar and have been able to write and recover data. Besides the
>> amrestore listing is out there.
>>
>># mt commands seem to run progressively longer as I read the tape,
>> I'm apparently writing lots of something between EOF marks, I'm
>> just hoping that its actual data.
>>
>># ls -las  /dev/sdlt2
>>lrwxr-xr-x    1 root  sys  20 Nov 22 14:45 /dev/sdlt2 ->
>> /dev/rmt/tps1d4nrnsv
>>
>>ie, bus 1, target (SCSI id) 4, non-rewinding, non-bytes-wapping,
>> variable length records. Similar to what I run on other systems.

Seems ok so far, let's debug the upper points first.
-- 
best regards,
Stefan

Stefan G. Weichinger
mailto:monitor AT oops.co DOT at