Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Alex
Paschal
Sent: Friday, January 11, 2013 11:57 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Deduplication candidates
I second Wanda on the logs. When you think about it, logs are unique data,
Interesting idea -- Let us know what you find out!
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rick
Adamson
Sent: Friday, January 11, 2013 2:03 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Deduplication candidates
Thanks Wanda and
To: ADSM-L@VM.MARIST.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 T
, January 11, 2013 9:22 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Deduplication candidates
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 O
he DB itself is
compressed).
Poor dedup on the Oracle logs either way.
W
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rick
Adamson
Sent: Friday, January 11, 2013 8:44 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Deduplication candidates
lto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rick
Adamson
Sent: Friday, January 11, 2013 8:44 AM
To: ADSM-L@VM.MARIST.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 20
Behalf Of
bkupmstr
Sent: Friday, January 11, 2013 7:15 AM
To: ADSM-L@VM.MARIST.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
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
f
We are evaluating the potential usefulness of TSM deduplication on our
Version 6 TSM servers. The servers run under zSeries Linux and are
currently at the 6.2.2.0 level. We would not start using deduplication
without upgrading to 6.2.4.0 or higher.
Parts of our workload, such as database backups s