Hi All

How does one determine whether client-side deduplication is working for
API clients?

I have a couple of test systems, a TSM 6.2.0.0 server (UNI01) and a
6.2.2.0 server (UNI00).  UNI01 has been backing up its database, server
to server to UNI00 for 6 months or so.  After upgrading UNI00 to 6.2.2 I
turned on deduplication for the server-to-server pool used for DB
backups.  The identify process did its thing and I saw deduplication
happening in the pool.

After a week or so of this I have created a client option set on UNI00
for UNI01 and turned on client side deduplication.
The source (UNI01) db backup summary record shows the same sort of
volumes as it did before the change.
There is no summary record on the destination (UNI00) that correlates
with the source DB backup.  There are accounting records but these show
no difference, and the archived data and network data are the same size
within a few bytes.
There is no actlog message on the source side to show that the DB
backup was deduplicated or what the deduplication benefit might be.
despite that, the amount of work that the identify process is doing per
backup seems to be less than it was before client side deduplication was
turned on, which is what would be expected.

I need this to work before 6.2 goes full production as I have two
datacentres some distance apart with a small but adequate pipe between
them. 5.5 full/incremental server to server DB backups work fine, but
incrementals aren't available in 6.2.

So the specific question is how do I tell if client-side dedup is
working in the server-to-server case.  But, more generally we have three
sources of information about client backups: Actlog, summary and
accounting.  BA clients dump their dedup stats to the actlog, but API
clients don't have that luxury. Summary and Accounting record formats
don't seem to have had this information included.

Regards

Steve.

Steven Harris
TSM Admin, Paraparaumu, New Zealand