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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Paul Zarnowski
Sent: Friday, February 15, 2008 8:54 AM
To: ADSM-L AT VM.MARIST DOT 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: psz1 AT cornell DOT edu