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: [EMAIL PROTECTED]
