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: psz1 AT cornell DOT edu