Reading thru this thread, no one has mentioned that backup will be slower
than archive -- for TWO significant reasons:
1. The "standard" progressive-incremental requires alot of work in comparing
the attributes of all files in the affected file systems, especially for a
LARGE number of files/directories (whereas archive has minimal database
overhead -- it just moves data).
2. Writes to disk are NOT as fast as tape IF the data can be delivered to
the tape device at "streaming" speed;  this is especially true if using
no-RAID or RAID-5 for disk pool striping (with parity)... RAID-0 might
compete if multiple paths & controllers are configured.  The big advantage
to disk pools is more concurrent backup/archive operations, then
disk-migration can stream offload the data to tape.

So, firstly, debug fundamentals using tar and archive commands (to eliminate
db overhead comparing file system attributes to identify "changed"
files/objects);  once you are satisfied with the thruput for archive, allow
20-50% overhead for daily incremental. If your best "incremental" experience
is not satisfactory, (but archive is okay) consider other options discussed
in the performance-tuning papers -- such as, reducing the number of files
per file system, use incrbydate during the week, increase horsepower on the
client machine and/or TSM server (depending on where the incr. bottlenecks
are).

The SHARE archives do not yet have the Nashville proceedings posted; when
they do show up, they are in the members-only area  (I was just there,
searching for other sessions).