At 10:10 AM 2/15/2008, Colwell, William F. wrote:

I don't see any need for new targeting features, they wouldn't do much in
my 'dream system'.

Bill, here's my thinking:

dedup in TSM isn't gonna come for nothing.  It will take additional server
resources to run the fingerprinting, reduction and reclaims.  You're gonna
want to do a lot more reclaim activity.  (VTL offloads this deduplication
processing from the TSM server)

We have lots of data, all over the spectrum.  I know we have a lot of
duplicate data, and I think I have a fairly good idea about where it
is.  I'd like to segregate that duplicate data into a separate storage
pool, and only de-duplicate that storage pool.  This would save the
overhead of deduplicating all the data that doesn't have a high duplication
rate in the first place.

Of course, if you've got enough money to buy all the horsepower and
capacity you need, then this isn't as big an issue.  I'm always trying to
think about how to optimize things.  It's possible this is overkill - I
don't think we'll really know until we have v6 up and running and see how
well it works.

3 advantages that a VTL will have over TSM deduplication:

1. LAN-free backup support
2. VTLs will perform data compression in addition to deduplication
3. VTLs will deduplicate across all data in the VTL.  TSM will only
deduplicate within a storage pool.  If you have 1 TSM server instance with
1 storage pool then this isn't an issue.  We're up to 10 instances, so
right off the bat, we see a 20:1 ratio between VTL and TSM (assuming 2-1
compression).

..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