We are following a very similar trajectory to yours.  I realize that CSD will 
not address chunk expiration, but it seems to me that it would decrease backup 
times, perhaps significantly.  We have not yet deployed 6.2, so I do not have 
first-hand experience.  As you realize, things are always a tradeoff.  Shorter 
backup windows vs shorter expiration windows in this case.

We do have some Exchange users who backup over slower networks.  We also have 
copy storage pools at a remote site, where bandwidth is a concern.  Using CSD 
and moving the remote copy storage pool from tape to disk could significantly 
decrease the bandwidth requirement for maintaining copies of all those PST 
files that get backed up every night.

And yes, Eudora (and Cyrus) were much easier to backup than PST and Exchange 
are!

..Paul


At 03:04 PM 11/16/2010, Colwell, William F. wrote:
>Hi Paul,
>
>I haven't installed 6.2 yet so I haven't tested client side dedup (CSD).
>But I don't think
>I would apply it to PST files anyway.  CSD doesn't solve the problem of
>chunk expiration.
>But if the network folk told me the network was overloaded and could
>prove that backups were
>the problem, then yes I would try CSD.
>
>6 years ago Draper Lab was using Eudora for an email client.  Eudora
>detached attachments
>to a folder where they were backed up once; backups of email were not a
>problem for TSM.
>But then we wanted to get into calendaring.  So we tried the Oracle
>Collaboration Suite
>which required outlook as a client.  So everyone's Eudora folders were
>sucked into PST files.
>Since our users are not restricted about how much email to keep, they
>kept pretty much
>every email and still do.  The result was huge PST files; there are
>100's of PST files
>larger than 10 GB.
>
>Of course there was no planning for backing up the new PST files;  I had
>to scramble.  I
>directed them to a separate storage hierarchy and changed the policy
>from 10-90-5-180 to 3-7-5-180
>to expire them much quicker.  This made for a pool of tapes which rolled
>over
>quicker so I could keep my media expenses under control.  My current
>policy on v6 is very similar.
>
>Well, the OCS was a failure so in came Exchange about 5 years ago.
>
>My idea of the best way to deal with PST files is to ban them entirely.
>Instead have unlimited
>quotas in Exchange and deploy an exchange backend archiving product to
>keep the exchange db
>manageable.  Some of the mail managers think this is a good idea too,
>but we are now in the
>midst of a drawn out exchange 2010 implementation so there are no
>resources to get serious
>about an archiving backend.
>
>Thanks,
>
>- bill
>
>
>
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
>Paul Zarnowski
>Sent: Tuesday, November 16, 2010 1:42 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: De-dup ratio's
>
>By using source-mode deduplication, you could avoid backing up the
>entire PST files every day.  We've just introduced Exchange here, within
>the last year, and are still figuring out the best way to deal with PST
>files.
>
>At 10:51 AM 11/16/2010, Colwell, William F. wrote:
>>But I won't start deduping PST's again because they are backed up every
>>day and I only keep 3 versions
>>so why do all the dedup effort only to have to go thru the chunk
>>deletion effort 3 days later?
>>Then I would have to reclaim the volumes to actually get the space
>back.
>
>
>--
>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


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