On Friday 20 September 2002 23:35, Neil wrote:
>Hi guys,
>
>Looks like my amanda is getting better. :)
>
>Take a look at the email report that amanda sent me.
>http://restricted.dyndns.org/amandareport.txt
Looks good, but it appears from the kb/s rate you are getting, that
the drives hardware compression is turned on, which doubles the
effective data rate. Thats a maximum of a 400kb/s drive without
that.
However, this also means that the true tape capacity is hidden from
amanda because amanda has no idea of the compression ratio the
hardware achieves. This is why there is a tapetype definition in
your amanda.conf.
Turn the drives compression off, and switch the dumptype chosen in
the disklist to something which uses "compress server best", which
should put gzip to work on those partitions that contain
compressable data. It will take time during the run to do this,
but the compression ratio can be in excess of 5/1 instead of the
drives average of 2/1.
>And here is my new amanda.conf.
>http://restricted.dyndns.org/amanda.conf
Your generated tapetype also indicates the compression in the drive
was on as its not quite up to the real capacity of a DDS2 tape.
>And here is my new disklist.
>http://restricted.dyndns.org/disklist.txt
Obviously it worked, but the final "." in the path isn't required.
>I only have 1 tape HP DDS-2. Then I wanted to do a full backup of
> my whole freebsd system everyday at 11pm.
>
>Since it's just 1 tape, is it alright if I configured my device in
>amanda.conf as /dev/nrsa0 (non-rewinding)?
Thats the correct way for amanda, she will do her own rewinding.
>Please comment on my amanda.conf.
Turning the drives compressor off is bit tricky since the tape has
now been written to in the compressed state. What you must do now
is to not only turn the dipswitch on the drive to off, but you must
cause the updated status to be written to the tapes internal
header, one you can't read or write to directly so you have to beat
the drive about the brow a bit to get this updated.
Do something along these lines:
1) dd if=/dev/sra0 of=scratch count=1
which will save the tape id data for amanda. By using the rewinding
device, we don't have to.
2) mt -f /dev/sra0 compression off
3) mt -f /dev/sra0 datcompression off
which will turn the compression flags back off that were turned on
when the tape was recognized by the drive.
4) dd if=/dev/zero of=/dev/sra0 count=1600000
Which will fill the drives buffer and force the drive to write to
the tape with those compression flags turned back off. If enough
data isn't written to the drive to cause this, those flags will
remain on forever *for that tape* even if the dipswitch is off.
5) rerun the tapetype and get the true capacity of the tape so you
can update that entry in your amanda.conf. It should go up a bit
because tapetype uses /dev/urandom as the data source for its test
writes, and the data from /dev/urandom is so random that it
overpowers the hardware compression and actually grows to be larger
on the tape than what tapetype seems to think it is.
6) dd if=scratch of=/dev/sra0 count=1
which will restore the amanda label to the tape. The rest of the
data on the tape will be gone however until you run another pass of
amdump. Note that I used the rewinding tape device for all of the
above. Otherwise we would have needed to do it manually with yet
more mt commands.
I have my own disklist entry for /usr broken up into an entry for
each subdir in /usr because I have a few subdirs there that contain
data thats already been compressed, much of it with bzip2, so I use
a dumptype for each directory that fits the data in that directory.
Initially set them all to use compression, and look at the email
report, any subdir thats reports a compression ratio over 100%
needs to be taped as is without further attempts at compression.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.15% setiathome rank, not too shabby for a WV hillbilly
|
