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.
>
>I don't wish to diminish the thanks but must sadly ask for further
> help. Unfortuanately I have yet another issue... but we'll get to
> that later.
>
>Currently we are using the jukebox, have DLE types of both xfsdump
> for the root and /usr1 partitions and of type TAR (gnutar) for DLEs
> that match the (top of partition) user directories on the Raid
> Array (.86 Tbytes).
>
>I've assigned a directory on the raid array to act as the work area
>(but was careful to not list it as a DLE) and have increased the
> maxdump to something larger than 1. We are still client contrained
> but 3 concurrent dumps is an aweful lot better than one. [I should
> also say that this system is the sole client of the server resident
> on this system]. I have also set the dump cycle to 2 weeks rather
> than one.
>
>I'm planning to dump 2-3 times per week but have been starting the
>process manually (via the # at command) and have seen dumps in only
>50 hours, down from hundreds when I initially started the server up.
>
>By all accounts everything is working properly, some tuning is still
>in order but there are no apparent errors. Or where not until I
> tried to test the file restore process.
>
>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
>
>
>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. 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
>
>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.
>
>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.
>
> Thank you all for your help, past, present and future,
>
> Brian
>
>---
> Brian R Cuttler brian.cuttler AT wadsworth DOT org
> Computer Systems Support (v) 518 486-1697
> Wadsworth Center (f) 518 473-6384
> NYS Department of Health Help Desk 518 473-0773
The two things I'd question are: what version of tar? We've found
that tar-1.13-19 and 1.13-25. We've had a report of 1.14 not working
a week or 2 back up the log. And earlier versions than 1.13-19 were
mistakenly putting a number of some kind at the start of the header,
which wasn't compatible with manda.
And I'd observe that amanda generally uses a fixed length record.
Back when I was running real tapes, I found that a 32kilobyte record
was measureable faster than the default of 512 bytes. But, if
everything isn't set to the same record length, the whole thing blew
up for me. Is there any way you can make it run fixed length records
on that lashup?
Generallly speaking, this record length, and the state of the hardware
compressor are both encoded in a pre-header on the tape, and once the
tape has been written badly, it must be fully rewound, the settings
changed, a new label written, followed by sufficient junk data
from /dev/zero to force the drive to flush its buffers, at that
point, and only at that point, will the drive rewrite that hidden
header on the tape with your new settings.
That said, I didn't relabel the tapes, but read out the existing label
to a scratch file with dd, rewound the tape, changed the settings and
dd'd that scratch file back to the drive followed by 100000 records
from /dev/zero, all with dd.
That was about 5 minutes faster per tape and didn't mess up amanda's
view of her world with amlabel. I also put those mt commands to set
the record size in my rc.local file so they were done at boot time,
and it worked IF there was a tape in the drive at the time. There
must be for the mt stuff to work correctly.
mt has the commands required to set the record size used.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.31% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
|
