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