At 05:59 PM 6/16/2011, Nick Laflamme wrote: >We need to do a bake-off -- or study someone else's -- between using >deduplication in a DataDomain box and using both client-side deduplication and >server-side deduplication in TSM V6 and then writing to relatively >inexpensive, relatively simple (but replicating) storage arrays. However, we >keep pushing the limits of stability with our TSM V6 servers, so we haven't >dared tried such a back-off yet.
Nick, We are heading down this path. My analysis is that in a TSM environment, the fairly low dedup ratio does not justify the higher price of duduping VTLs. Commodity disk arrays have gotten very inexpensive. We're using DS3500s which are nice building blocks. We put some behind IBM SVCs for servers, some attached to TSM or Exchange servers (without SVC). Common technology - different uses. We use them for both TSM DB, LOG and FILE (different RPM disks, obviously). Using cheap disk vs VTLs has different pros and cons. using disk allows for source-mode (client-side) dedup, which a VTL will not do. VTLs, on the other hand, allow for global dedup pools and LAN-free virtual tape targets. deduping VTLs will be more effective in TSM environments where you have known duplicate data, such as lots of Oracle or MSSQL full backups, or other cases where you have multiple full backups. For normal progressive incremental file backups, however, TSM already does a good job of reducing data so VTL dedup doesn't get you as much, and in this case IMHO cheap disk is, well, cheaper and gets you source-mode dedup as well. We are in process of implementing this, but I know a few others are a bit further along. We will continue to use TSM Backup Stgpool to replicate offsite. ..Paul -- Paul Zarnowski Ph: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801 Em: p...@cornell.edu
