I second Wanda on the logs.  When you think about it, logs are unique
data, being entirely made of transactions in the order in which they
come in.  If they were identical to some other data, I'd start looking
around for Twighlight Zone cameras.

On the other hand, I suppose I could imagine a test harness issuing the
exact same set of transactions to a test system multiple times.

On 1/11/2013 7:21 AM, Prather, Wanda wrote:

Yep.

Oracle DB's, getting great dedup rates on the DB's (except the ones where they 
have turned on Oracle compression to start with - that is, the DB itself is 
compressed).

Poor dedup on the Oracle logs either way.

W

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

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