Hi Stefan,

Using compression will really slow down the backup - mostly in backup
mode, but in restore as well. If you set the format parameter in the
device class to drive (instead of a fixed number) you will get both the
benefit of a dynamic device class with regard to number of drives (for
additional drive installations and drive failure(s)) and you will enable
automatic hardware compression. This compression is better than the
software based compression, however when the system is queried, the
number returned will reflect raw data sizes, not compressed data sizes.
Client side (software based) compression or server side (software based
compression) will work in conjunction with library based hardware
compression however you will not receive any compression benefit by
running both and the numbers returned upon query will not reflect the
actual size of data on the tape. In some cases an already compressed
file has taken 15 minutes while software based compression tried to
re-compress it. The impact is not small.

Remember, this is based on the device class specification of
format=drive, and may not be applicable to all drives, but only those
with compression capabilities. We currently use LTO based native fiber
drives. 

Choosing one method of compression over the other will improve
performance and specifying hardware compression while forcing off
software compression should really improve performance.

Another neat performance tuning trick (as I'm sure you already know) is
to backup to a hard drive initially, and then force migration (set the
pool to migrate hi=0 lo=0 in a script, and then set it back to normal
again after an hour or so) to de-stage the data off the hard disk and
onto tape. This allows multiple sessions (sessions are not limited to
number of available tape drives) and hard disk is generally faster as a
storage pool.

Let me know if this helps,

Kevin.