Note: tar -z uses gzip for compression which is already pretty
strong. Whether you manage to get the stuff on a tape or not strongly
depends on the kind of data you have - if the data is already
"sort-of" compressed or hardly compressible (e.g. encrypted data) then
gzip might just get you the few additional bytes, that you don't get on
the streamers hardware compression.
Just check the data you have:
[already compressed - gzip won't be able to compress it, old BAD
compressions like ARC would even result in the
"compressed" for to become LARGER than the
original]:
- do you have many .zip/.tar.gz/... archives to back up?
- linux packages (.rpm, .deb, .slp)?
- how much of the data is image data (jpg/gif/compressed tiff)?
[high noise data - highly irregular data (sounds, ...) are difficult
to compress, resulting in lower compression rates]
- how much is sound data (wav, mp3, ...)?
- how much of the data is encrypted?
[highly compressible data]
- how much of your data is ASCII/HTML files (also mail folders)?
- how much of your data is structured data (CSV, binary dumps of
program data)?
While the first two sections will make the tape drive cough (when trying
to compress the data), the third will help you to get "more" data on the
tape, as the hardware compression will have a rather easy job (still -
gzip would still get a higher compression rate on these).
Another potential show stopper are large files, that processes are writing
to while you're doing the backup. I don't know about tar, but some
software just tries to back up the file as often as it takes to get the
file on there without any changes during the backup. This might waste a
lot of space. Good candidates for this kind of problems are databases,
system logfiles and the like.
Benedikt
ULTIMATUM, n. In diplomacy, a last demand before resorting to concessions.
[Ambrose Bierce, "The Devil's Dictionary"]
