----- "Andrew Raibeck" <storman AT US.IBM DOT COM> wrote:


> > Any one know anything about this ...
>
> > ... and how to avoid its effects?
>
> a) Hardware deduplication in your TSM server storage.
>
> b) TSM deduplication (6.1 and up for server-side, 6.2 for
> client-side)
>
> c) Progressive incremental backup of the system state's System Writer
> component (TSM 6.2 client, compatible with TSM version 5.5 and 6.1
> servers)
>
> (a), (b) and (c) help reduce TSM server storage requirements.
>
> (c) also helps reduce impact to the TSM server database.
>
> Best regards,
>
> Andy

Just a side note to Andy's comment - if I understand it correctly, the dedup in 
TSM works with file pools only.  Regrettably that means there's no saving in 
tape slots, TSM database size, copy pool tapes, etc., but it does allow a heap 
more data to be stored within a file pool, and with the features in 6.2 this 
can be realized immediately rather than only after processing.

Hardware dedup - e.g. ProtecTIER - is a more complete way to save on TSM 
storage, but comes at a cost which may or may not be justified by the savings 
in space alone.

What's the impact on restoring the system state when using (c) above?  I'm 
guessing eventually it means more tape mounts unless there's some pretty 
aggressive collocation going on.