On Monday 07 July 2003 13:26, Joshua D. Bello wrote:
>I am currently experiencing problems with Amanda backup runs
> completing successfully, supposedly due to running out of tape. I
> am using Amanda 2.4.3 on a FreeBSD 4.8-STABLE machine, backing up
> to 35/70GB DLT 7000 drive. Compression is enabled on the drive,
> and we are also using compression within Amanda. We are getting
> nowhere near the expected 70GB compressed capacity of the tapes.
>
>I would guess that something is misconfigured somehow, and I am
> simply not catching it. If somebody else has suggestions or
> information on how to deal with these problems, it would be greatly
> appreciated. Thanks in advance!!
>
>--Joshua D. Bello
>
As Joshua Baker-LePain says, bad, bad, bad.
You cannot use both compressions. In doing so, its quite likely that
the data, already being compressed, will expand enough that what
amanda thinks is 35Gb of data, measured after compression, will be
enough over 35Gb to cause the tape to hit EOT, its full.
That 70Gb rating is what you'll get under ideal conditions using
hardware only compression on 'sparse' files.
Feed that HW chip a tar.bz2, and some are smart enough to step aside,
but if it doesn't, the file will grow.
You have 2 choices. You can shut down the software compression and
let the drive do its thing. The disadvantage to that is that you'll
have to lie to amanda and set the tapetypes capacity down 15 to 20%
from the 70Gb the makers use as sales propaganda. This will be
required because amanda has no way to tell how many bytes have
actually been written to the tape when the HW chip is in use.
Or you can shut down the hardware compression. That will probably
take a conversion routine applied to each tape to get rid of the
"hey, I'm compressed" flags that will turn the compression back on
even when the dipswitch has been set to off, this so that the drive
can read a formerly compressed tape. Unforch, it seems to carry over
into the next write, maintaining the status quo.
Anyway, once thats done, then amanda can compress, probably better
than the hardware can, and it keep track of the files compressed
size, so it can know to within 1% of the tapes raw capacity just how
much has been written to the media. That would be 35Gb in your case.
Generally speaking, this group tends to recommend against useing the
hardware compressor, particularly if the tape drive is a bit small
for the job because the software can do a better job of squeezing,
averageing around 40% of the input size for the output size.
Those of us who are "drive challenged" (lets face it, nothing compares
in cost per megabyte to an old DDS2 drive) will often break our
disklists up into smallish pieces just so we can compress that which
can be compressed, and skip that which doesn't compress.
But those are the sorts of things you learn after running amanda for a
while, paying attention to the emails amanda sends you.
>Relevant info:
>
>## mt status output ##
>
>Mode Density Blocksize bpi Compression
>Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC
>---------available modes---------
>0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC
>1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC
>2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC
>3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC
>---------------------------------
>Current Driver State: at rest.
>---------------------------------
>File Number: 0 Record Number: 0 Residual Count 0
>
>## Relevant lines of amanda.conf ##
>
>define tapetype DLT7000 {
> comment "Quantum DLT7000"
> length 35000 mbytes # 35Gb tapes
> filemark 8 kbytes # as per all examples
> look like this
> speed 10 mbytes # not sure about this just yet
> #speed 2500 kbytes
> }
>
>## An example of the lines in disklist ##
>
>ra / comp-root
>ra /var comp-high
>ra /usr/local comp-user
>ra /local0 comp-high
Break this up into much smaller pieces, staying at no more than 5% of
the drives 35Gb capacity. This will allow amanda to fine tune the
schedule, eventually arriving at a very consistent amount of tape
useage per run, but this will be over a few dumpcycles before its
well settled. When its all in one swell foop like '/' above, amanda
doesn't have anything to use for 'wiggling room', which is also
contributing to your EOT problems
I am doing 4 disks, in 2 machines here, with 44 entries in my
disklist. A total of over 60Gb on about 210 Gb of disks, not all of
which is in the disklist. After compression, I'm writing around 3.4
Gb per run on DDS2 tapes with a tapecycle of 28, dumpcycle and
runspercycle of 7.
Tonight I'm going to see if I can squeeze my firewalls /usr/local into
a 45th entry. It should compress fairly well, like its /usr/src
does. Both of those will often come back out at less than 30% of the
input size.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
|
