Interesting idea -- Let us know what you find out!
-----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 2:03 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Deduplication candidates
Thanks Wanda and Alex,
Yes I too thought about the uniqueness of the data that makes up logs.
I guess I'm just second guessing myself.
One approach I am thing about in regard to the same issue with pre Exchange
2010 log files (legacy incrementals) is if it wouldn't be better to just do
full backups. Aside from the time-to-completion, overall storage requirements
may be the same and would in most cases speed recovery.
~Rick
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Alex Paschal
Sent: Friday, January 11, 2013 11:57 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Deduplication candidates
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.
> +---------------------------------------------------------------------
> +-
>
|
