Gene Heskett writes: > 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.
Are you saying that setting hardware compression to off is better? > > 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 How will I be able to do that? From what I have in my http://restricted.dyndns.org/amanda.conf, amanda is using dump utility. Am I correct? And I heard that dump is the best tool to backup our file system. When does gzip comes into play? > 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. > > > 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. Ok, after dd finishes, I will run tapetype again. > 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 I tried this but scratch file was not populated. > 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 Mine worked as mt -f /dev/rsa0 comp off > 3) mt -f /dev/sra0 datcompression off I "man mt" but didn't find similar option as above. > 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 it's running right now :) > 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 Since my scratch file wasn't populated, I will have to run amlabel after dd finishes. > 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. Thank you very much Gene and to other folks here. This is an awesome support. This is what I like very much in the Open Source community. :) Neil
