About deduplication, Mark Stapleton said:

> It's highly overrated with TSM, since TSM doesn't do absolute (full)
> backups unless such are forced.

At 12:04 AM 2/15/2008, Curtis Preston wrote:
Depending on your mix of databases and other application backup data,
you can actually get quite a bit of commonality in a TSM datastore.

I've been thinking a lot about dedup in a TSM environment.  While it's true
that TSM has progressive-incremental and no full backups, in our
environment anyway, we have hundreds or thousands of systems with lots of
common files across them.  We have hundreds of desktop systems that have a
lot of common OS and application files.  We have local e-mail stores that
have a lot of common attachments.

While it may be true that overall, you will see less duplication in a TSM
environment than with other backup applications, with TSM you also have the
ability to associate different management classes with different files, and
thereby target different files to different storage pools.  Wouldn't it be
great if we could target only the files/directories that we *know* have a
high likelihood of duplication to a storage pool that has deduplication
capability?  You can actually do this with TSM.  I'd like to see an option
in TSM that can target files/directories to different back-end storage
pools that is independent of the "management class" concept, which also
affects versions & retentions and other management attributes.


..Paul



--
Paul Zarnowski                            Ph: 607-255-4757
Manager, Storage Services                 Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801    Em: psz1 AT cornell DOT edu