On 2008-02-14 04:16, Nigel Allen wrote:
Hi
I have a client running FC6 with an HP StorageWorks DAT72 USB internal
tape drive which according to the documentation can do 36G native and up
to 72G compressed. We are trying to use Amanda to just back up the
server so it is configured as both server and client.
We ran amtapetype on it which suggested a tape size of around 32GB.
[...]
> FAILURE AND STRANGE DUMP SUMMARY:
> mail.xxxx.com.au mapper/VolGroup00-LogVol00 lev 0 FAILED [dump
larger than available tape space, 53330360 KB, but cannot incremental
dump new disk]
Indeed 53 Gbyte backup image does not fit in 32 Gbyte tape.
The disklist looks like this:
> mail.xxxx.com.au mapper/VolGroup00-LogVol00 high-tar
> mail.xxxx.com.au sda1 high-tar
(sidenote: when using tar, why do you use device names? not not
directory names?)
and current disk usage is:
> Filesystem Size Used Avail Use% Mounted on
> /dev/mapper/VolGroup00-LogVol00
> 225G 52G 162G 25% /
> /dev/sda1 99M 11M 83M 12% /boot
> tmpfs 252M 0 252M 0% /dev/shm
I'm obviously missing something here - I understood that amanda would
take the compression into consideration. Should I be using software
compression or hardware? If software, how do I turn of compression on
the tape device?
I think you missed to configure the correct tapetype definition to
72 Gbyte in the experiment.
Find if Amanda thinks the same about the config you changed:
amgetconf DailySet1 tapetype
note the output: this is the tapetype that Amanda will use;
let's assume the output was "DAT72"; then try:
amgetconf DailySet1 tapetype:DAT72:length
And Amanda shows the output in Kilobytes.
But the real solution:
If you have the CPU-power, then software compression is surely better
than hardware compression when using DAT72 tapes.
But, make sure you have the hardware compression disabled,
otherwise you actually loose 20% capacity by the dumb hw-comp algorithm
on those tapedrives that expands uncompressable data.
To disable hardware compression, see:
http://wiki.zmanda.com/index.php/Hardware_compression
When estimating, Amanda makes a dummy backup, and notices the output
of tar indicating the total bytes output. For compression, it assumes
a ratio learned from the previous dumps. When no history exists, Amanda
assumes a ratio, that you configure in amanda.conf with the "comprate"
parameter, which defaults to 0.50 (= compression to half).
If this is indeed the first backup ever of that DLE (as the message
says "...cannot incremental dump new disk"), then you have to figure
out why Amanda thinks "53 Gbyte * comprate" is more than 32 GByte.
Look carefully in the parameters like "comprate" from:
amadmin DailySet1 disklist mail.xxxx.com.au mapper/VolGroup00-LogVol00
For DLE's that had already some backups run, you can find out the
historical data that Amanda uses to compute the comprate with:
amadmin DailySet1 info somehost /some/disk
--
Paul Bijnens, xplanation Technology Services Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: [EMAIL PROTECTED]
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************
