We backup complete end user desktops. Ever since the advent of TSM - actually adsm 1.1 - some people, mostly managers, have asked how many copies of any file, for example winword.exe, are stored in tsm. When I tell the 1,200, I can see they are thinking 'what a waste, what's wrong with tsm'. So I am looking forward to being able to say 'just one copy'.
According to the Oxford presentations, tsm software dedup will only happen during reclaim and the storage pool is a devtype=file sequential disk pool. I don't see any need for new targeting features, they wouldn't do much in my 'dream system'. I am spec'ing out a new system now. Before hearing about version 6, I wanted a vtl. Now my dream system is an x-series running linux and version 6 with midrange raid for the database and backuppool and 50 - 100T of sata arrays. No tapes for primary pools. Thanks, Bill Colwell Draper lab -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Paul Zarnowski Sent: Friday, February 15, 2008 8:54 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: TSM dream setup >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]