Though our TSM systems (6.3 and 5.5) use back-end de-dup, data domain, I also 
notice that log files for DB's such as Exchange pre 2010 using legacy backups 
and DB2 log files de-dup very poorly.
Originally I thought that our DBA's or Exchange admins were either compressing 
this data or storing it on compressed volumes but I found no evidence of it. 
After seeing this conversation and giving it further thought I wonder if others 
experience poor de-dup rates on these data types?
Thanks
~Rick

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
bkupmstr
Sent: Friday, January 11, 2013 7:15 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Deduplication candidates

Thomas,
First off, with all the great enhancehancements and current high stability 
levels I would recommend going straight to version 6.4 As you have already 
stated there are certain data types hat are good candidates for data 
deduplication and your database backup data definitely is and image files 
definitely aren't.

>From my experience oracle export files are traditionally good dedupe 
>candidates also.
>From what you describe, the SQL backup data minus the compression would also 
>be a good candidate.

The one thing you do not mention is how many versions of this backup data you 
are keeping?

>From my experience, unless you are keeping a minimum of 4 backup versions, the 
>dedupe ratios will suffer. Too many time I see folks keeping only 2 backup 
>versions nd they can't understand why they get very poor dedup rates

Also be aware that with TSM deduplication you will have to ensure that you 
write the backup data to a target disk pool that  will have good enough 
performance to not negatively impact backup speed.

+----------------------------------------------------------------------
|This was sent by bkupmstr AT yahoo DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------