>>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 <michael_s.ryder AT roche DOT 
com
> 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
>