>>Aside from distribution of processing, are there clear benefits one way or the other, between client-side and server-side de-dupe?
Client-side dedup has a impact on backup storagepool to tape performance. Client-side dedup is much more reclaim (and reuse delay) friendly. Client-side dedup basically requires an SSD based TSM database while server side doesn't but I would stick with it anyway, client-side dedup performance is very much effected by the TSM database performance. Client-side dedup doesn't have the safety net of having "never-deduped" data on tape that some people like. On Mon, Sep 15, 2014 at 2:57 PM, Ryder, Michael S <[email protected] > wrote: > Hello TSM folks... > > What is the prevailing opinion of TSM de-duplication? > > I'm in the middle of building out a fresh TSM 7.1.1 install (on RHEL6, > x86_64, w/TDP for VE {vsphere}), and the de-dupe feature could really come > in handy -- I've already read the documentation and believe I have enough > infrastructure to support it. > > Is it stable? Are there any "gotchas" that are perhaps not obvious to > someone who is only reading the documentation and hasn't implemented it > yet? > > Aside from distribution of processing, are there clear benefits one way or > the other, between client-side and server-side de-dupe? > > Thanks in advance for time spent on replying to my question! > > Best regards, > > Mike, x7942 > RMD IT Client Services >
