We have been in production with our DD for about 18 months now. We have
about 20TB of native storage on the DD.
We are currently using about 16TB of the native storage and have fit
about 195TB of TSM data onto the disks, which comes out to a 12-to-1 ratio (or
about a 91% reduction in space).
Our approximate percentages of data are:
40% VM image backups (fulls & diffs)
35% DB dumps (Exchange, MSSQL, Sybase)
20% fileserver backups
5% misc (TSM DB dumps, DR documentation).
At one point in our use, we hit a high of about 22-to-1
compression. At that peak we were using Vranger to do full backups once a week
of our VM clients (about 500 VMs). Unfortunately, the backups were taking
longer than the weekend (because they were uncompressed) and bled over to the
weekdays. To get around this, we now do differential backups of the VMs. The
backups now fit into the weekend time-frame because the differentials are
smaller, however, the de-dupe stats go down because differentials don't get as
much de-dupe. As is expected, our compression ratio went down, however the
actual usage of space on the DD did not go up very much. They kinda offset
eachother.
Overall, our experience with DD has been pretty painless and much more
hands-off than tape ever was. Restores are nice and quick, even with
non-collocated storagepools because the volume "mounts" happen in a couple of
seconds. When we are restoring large DB dumps from DD, we can get nearly full
bandwidth of the 1GB NIC with no problems.
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Kelly
Lipp
Sent: Monday, June 15, 2009 9:58 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Data Domain - questions from a meeting with DD
Ben,
How much data do you have in DD and what sort of ratios are you seeing? What
about performance during restores?
Thanks,
Kelly Lipp
CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777 x7105
www.storserver.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Ben
Bullock
Sent: Monday, June 15, 2009 9:52 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Data Domain - questions from a meeting with DD
We use a DD580 on our TSM servers. We use a device type of "FILE" and set it to
a 50GB file size. Our TSM server is on AIX, so we use an NFS mount for the
storage pools on the DD. It works well, we can get very good throughput over
the 1GB NIC to the DD. If your environment is larger and you need more
throughput, you could get a DD with the VTL option and then I think you can
attach it to your TSM server though fibre.
We try not to compress anything we send to TSM. Yes, it takes longer to send
over the network, but it then dedupes well. In some cases we do have to receive
pre-compressed data that will not depupe/compress. In those cases, we don't
send that data to the DD storagepool, we keep it on the tape drives.
DD has to do its own "CLEAN" process once a week, which is kinda like a
reclamation on the TSM server. So we just let the TSM server do it's normal
reclamation on the DD storagepools, but knowing that the data will not actually
re-appear on the DD until after it does it's clean.
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Loon,
EJ van - SPLXM
Sent: Monday, June 15, 2009 9:31 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Data Domain - questions from a meeting with DD
Hi Rick!
Quite a coincident: I just spoke to DataDomain too!
1) The Dutch guys also confirmed that compressed data is dedupable, but it
depends how compression is done. If it's file level compression, you can expect
that a copy of that file is similar and thus dedupable. A compressed
ntkernel.dll from system A is similar to a compressed ntkernel.dll from system
B.
2) and 3) The Dutch DD guys stated that most TSM users with a DataDomain
appliance use a storagepool type=disk!
Normally you don't want to store your data in a diskpool, because it becomes
heavily fragmented overtime, but since the DD appliance does backend
defragmentation, front-end fragmentation on you diskpool this will have no
negative effect on performance.
I found it a very interesting option, since the appliance does in-band and
on-the-fly deduplication, compression and defragmentation and has the option to
duplicate the de-duplicated data to a remote location.
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Richard Rhodes
Sent: maandag 15 juni 2009 15:29
To: ADSM-L@VM.MARIST.EDU
Subject: Data Domain - questions from a meeting with DD
Hello,
The other day we had a meeting with Data Domain - just the normal vendor update
about their products. While informative, several comments were made by DD
systems that I thought I like your opinions on. (note: we are a all tape
shop, and probably will be until the next hardware refresh in several years)
Interesting comments DD made:
1) de-dup of compressed data.
We told them that much of our backup load comes from Oracle backups that are
already compressed via Unix compress utility then pushed to TSM. We asked what
effect this would have on de-dup. They said we could expect a 4x-5x de-dup
ratio on this compress data. I had always thought that compressed data would
not de-dup.
2) NFS mounted storage pools.
They said that the vast majority of their installations, including TSM
installations, use NFS (some OpenStorage for NetBackup, and a little CIFS) for
backups to disk. In other words, VTL emulation is a very small percentage of
their installations. If you have DD hdwr, are you using NFS or file devices,
or, a vtl interface? Is anyone using NFS for a storage pool?
3) DD reclaim of scratch tapes
I asked about when/how DD will reclaim no longer used space.
In other words, when a scratch tape passed reuse-delay. He said that DD had
some kind of interface to backup softw such that it knows when data is no
longer needed and reclaimes that space. I know TSM v5.5 has a feature to clear
a vol when no longer used with a vtl, but DD was saying they had a special
interface to accomplish this. Does DD have a special interface to TSM?
Thanks
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.
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to this
e-mail or attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately by return
e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission of
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered number
33014286
**********************************************************************
The BCI Email Firewall made the following annotations
---------------------------------------------------------------------
*Confidentiality Notice:
This E-Mail is intended only for the use of the individual
or entity to which it is addressed and may contain
information that is privileged, confidential and exempt
from disclosure under applicable law. If you have received
this communication in error, please do not distribute, and
delete the original message.
Thank you for your compliance.
You may contact us at:
Blue Cross of Idaho
3000 E. Pine Ave.
Meridian, Idaho 83642
1.208.345.4550
---------------------------------------------------------------------
