On Friday 09 April 2004 04:49, Hans van Zijst wrote:
>It seems as if Amanda has a problem with my DLT drive. It's an HP
> DLT7000, an uncompressed tape has a capacity of 35GB, a compressed
> one up to 70GB. But when I do a full dump of all my machines on a
> time that one of them contains quite a lot of data (my own
> homegrown backup-images), I get this kind of report.
>
>Now, if I do my maths correctly, the tape (with hardware compression
> turned on) should be able to take at least 35 GB, the total size of
> the amanda dump is 43GB, so if the compression ratio is 0%, it
> should refuse less than 10GB. Amanda makes images of 2000MB, btw.
> But if the aready taped 14.6GB represents 20.9% of the tape's
> capacity, that would mean there's still room for 55.2GB.
>
>I'm not a mathematician, so either I'm making some mistake here, or
> I misinterpret Amanda's report. This is the drive definition I use:
>
>define tapetype DLT7000 {
> length 70000 mbytes
> filemark 1024 kbytes
> speed 1687 kps
>}
>
>Can anyone tell me what's happening here?
>
>
>
>*** A TAPE ERROR OCCURRED: [[writing file: No space left on
> device]]. Some dumps may have been left in the holding disk.
>Run amflush to flush them to tape.
>The next tape Amanda expects to use is: a new tape.
>
>FAILURE AND STRANGE DUMP SUMMARY:
> gandalf.de /var lev 0 FAILED [out of tape]
>
>
>STATISTICS:
> Total Full Daily
> -------- -------- --------
>Estimate Time (hrs:min) 0:03
>Run Time (hrs:min) 4:24
>Dump Time (hrs:min) 2:58 2:58 0:00
>Output Size (meg) 43587.3 43587.3 0.0
>Original Size (meg) 43587.3 43587.3 0.0
>Avg Compressed Size (%) -- -- --
>Filesystems Dumped 23 23 0
>Avg Dump Rate (k/s) 4184.8 4184.8 --
>
>Tape Time (hrs:min) 1:13 1:13 0:00
>Tape Size (meg) 14624.0 14624.0 0.0
>Tape Used (%) 20.9 20.9 0.0
>Filesystems Taped 22 22 0
>Avg Tp Write Rate (k/s) 3441.0 3441.0 --
>
If amanda is aslo useing compression, the data will be expanded some
by the hardware compressor as its already been compressed.
The true size of the tape is 35Gb. The 70GB is the maximum amount of
uncompressed data that can be put on that tape *under average
conditions* with hardware compression enabled.
Using hardware compression hides the true size of the data on the tape
from amanda, who counts bytes sent to the tape.
For all those reasons, the overall efficiency of tape usage recommends
that the drives hardware compressor be turned off, and software
compression applied to those disklist entries that actually can be
compressed. My own 44 entry disklist uses compression only if, when
set to be compressed, I get an email indicating that the compression
actually gained a data size reduction of over 10%. A directory full
of rpms and such is already compressed, so don't waste the cpu's
horsepower on them. OTOH, directories such as your /etc, can usually
be compressed to less than 20% of their original size. I use DDS2
tapes, with my tapetype showing its about a 3.7Gb tape because I have
another script that runs after amdump that archives and stores the
index files made during the run, and the amanda configuration that
made the tape.
I have, once in a blue moon to 2, gotten email reports that said it
put over 12Gb of data on that tape because everything that got their
level 0's that particular night was highly compressable. But, my
average, over the full run compression runs about 35%. From last
nights run:
STATISTICS:
Total Full Daily
-------- -------- --------
Output Size (meg) 3722.4 2894.9 827.5
Original Size (meg) 6256.9 4608.0 1648.8
Avg Compressed Size (%) 35.0 34.9 35.2
Avg Dump Rate (k/s) 965.7 1075.1 712.1
Avg Tp Write Rate (k/s) 393.4 394.0 391.1
So tape usage in this case was 102%, but since amanda thinks the tape
is smaller than it is, there was just barely room for my additional
data, and the whole session was a success.
So nearly all of us here recommend that hardware compressors look
great in the advertising, but amanda is much happier if they are
turned off because then amanda can know for sure, just how much data
can actually be put on the tape, Amanda counts those bytes sent to
the tape *after* any compression has been applied. Yes, it takes cpu
horsepower to do the compression, but if its done on the client
machines, then several dumps can be run in parallel and the average
speed dosn't suffer that much. You can use the spindle number option
in your disklist to control the amount of parallelism done. You
should give each physical disk its own spindle number.
For a tape that has been written with hardware compression enabled,
you must disable it from doing an automatic re-enable by manually
rewinding that tape with mt, then dd the label blocks to a scratch
file, then rewind the tape again, turn the compression back off with
the appropriate mt commands, then dd that scratch file back to the
tape using the non-rewinding device, followed by dd'ing enough data
from /dev/zero to overflow the drives buffer and force the drive to
flush to media, at which point the new, uncompressed status will be
finally written to the tape. Only then will the tape be considered
an uncompressed tape in many cases.
--
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.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
|
