----- "Andrew Raibeck" <stor...@us.ibm.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.
