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.

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.

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.

Thank you very much Gene and to other folks here.

Neil