We are sending about 90% of the data to the DataDomain. There is another 10%
that we have defined as being non-compressible and it goes to a management
class that points to a TSM disk pool that migrates to tape.
Ben (about to go on vacation for a week, so not likely to respond if there are
any follow-up questions ;-})
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Ochs, Duane
Sent: Thursday, June 25, 2009 3:52 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Dedupe
Ben,
Do you also keep your dedupped data cached on the DD and migrate to tape ?
Are you sending a specific subset of data to the DD ? Or everything ?
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Ben Bullock
Sent: Thursday, June 25, 2009 10:55 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Dedupe
We have a couple of DataDomain 580s here. If you look in the archives you will
find my comments on the rate of compression we are getting and my impressions.
As far as the "putting all your eggs in one basket" scenario, that always is
the worst case scenario. In our situation, we have been using the DD for about
18 months and have had no loss of data. The systems are constantly running a
"verification" that soak up all the free cycles to double-check that what it
thinks is on disk is on disk. It seems to run all the time, but doesn't seem to
interfere with the in-line compression going on or impact the speed of the
backups in the middle of the night.
We have done 1 code upgrade and 1 hardware upgrade in the last 18 months that
caused us to have to take downtime on the DD. Our first OS upgrade was done
just a couple of months ago as they released a new version that was supposed to
improve the speed of the systems anywhere from 50% to 100%. (I guess someone
decided to take the extra "sleep" statements out of the code ;-}). We just took
down the TSM servers for safety and then ran the command to upgrade. They
predicted up to 2 hours, but it actually took about 25 minutes. As for the
improvements, I can see the CPU having a much lower utilization rate than it
did before, but I have not really precent-ified the improvements.
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Rhodes
Sent: Thursday, June 25, 2009 9:04 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Dedupe
> I a dedup appliance, that is exactly what you don't have. The dedup
> process guarantees that only one copy is kept of each unique block of
> that data. If a given block of data is lost due to corruption or
> failure of the media, then potentially all of the copies of a certain
> file that contains that block of data will be lost. The people who
> are designing these products, therefore, build their products to
> mitigate this potential loss by:
This is exactly what scares me about dedup - the unit of recovery. For our
current (and foreseeable future) tape systems, the unit of loss and recover is
a TAPE. With a VTL/dedup it's a much larger unit which is hard to define, but
could be up to the entire appliance. A software bug could potentially take out
not only a local appliance, but a replication target.
When DataDomain was here a few weeks ago, I asked them if they have ever had a
data loss event. They quickly replied "NO". I wish I knew whether to believe
them - vendors do NOT like to acknowledge crashed systems.
Another question I asked - Why would I EVERY have to take your system down?
Their reply what that it takes about 2hr to perform a microcode load. Other
than that, it should never have to come down.
That then leads to a discussion of frequence of code releases and how quickly
one must upgrade. (I don't remember their answer)
There is a part of me that strongly wishes we had a VTL/dedup system, but
another part is very happy to be sitting out this round with all the vendor
consolidation and product changes.
( Note: I am a FIRM BELIEVER in the worse case scenario! )
Rick
-----------------------------------------
The information contained in this message is intended only for the personal and
confidential use of the recipient(s) named above. If the reader of this message
is not the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
document in error and that any review, dissemination, distribution, or copying
of this message is strictly prohibited. If you have received this communication
in error, please notify us immediately, and delete the original message.
mg_info.txt
Description: Text document
|
