Hi Eric,
I started doing dedup fairly soon after 6.1 became available. What I
found is that
the server had a lot of trouble expiring large files. After expire runs
and appears to
be done, the server has a lot of extra work to do before it actually
deletes chunks from
storagepools. And early in 6.1, this code had problems and was
inefficient. So I had
to stop deduping big files to get the server to run smoothly. Oracle
backups were very
bad this way and they weren't getting spectacular dedup ratios so I
stopped deduping and
returned to doing client compression which gets about 80% compression.
The process is much better now - I know this because I tested a lot of
patches to it - so I
am thinking of deduping 2GB files, and if all goes well then 4 GB etc.
But I won't start deduping PST's again because they are backed up every
day and I only keep 3 versions
so why do all the dedup effort only to have to go thru the chunk
deletion effort 3 days later?
Then I would have to reclaim the volumes to actually get the space back.
What I do now is back them up to their own storagepool directly to my
Sata filesystems using scratch
volumes. The storagepool is collocated by node. Every day at 17:30 I
update all volumes in the
pool to be readonly. This sets up a state of one file per volume. When
expiration runs and a PST
is deleted, the volume is deleted too and I get the space back
immediately - no reclaim process is needed.
All together this storage pool needs about 15 TB of space.
Thanks,
Bill Colwell
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Loon, EJ van - SPLXO
Sent: Tuesday, November 16, 2010 8:24 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: De-dup ratio's
Hi Bill!
Just out of curiosity, why do you exclude large files from dedup? When
for example a large PST file changes, probably only a small portion of
the file changes, so the rest of the file should be 'deduplicatable',
right?
Kind regards,
Eric van Loon
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Colwell, William F.
Sent: maandag 15 november 2010 16:12
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: De-dup ratio's
Hi David,
I am doing dedup with v6, no appliance involved.
On a server for windows systems, I am getting 3 to 1 savings. The 'q
stg f=d' command
shows the savings -
Duplicate Data Not Stored: 77,638 G (67%)
I exclude pst files and any other file larger than 1 GB from dedup.
On another server for linux, solaris, mac clients, the savings are -
Duplicate Data Not Stored: 26,558 G (58%)
I also exclude > 1 GB files and the oracle/rman backups.
Thanks,
Bill Colwell
Draper Lab
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Druckenmiller, David
Sent: Friday, November 12, 2010 11:24 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: De-dup ratio's
I'm curious what others are seeing for de-dup ratios for various
methods.
We're using IBM's ProtecTier for our TSM (5.5) primary pools and only
see about a 4 to 1 ratio. This is less than half of what IBM was
projecting for us. We have roughly 400 clients (mostly Windows servers)
totalling about 135TB of data. Biggest individual uses are Exchange and
SQL Dumps.
Just wondering what others might be getting for other appliances or with
TSM v6?
Thanks
Dave
-----------------------------------------
CONFIDENTIALITY NOTICE: This email and any attachments may contain
confidential information that is protected by law and is for the
sole use of the individuals or entities to which it is addressed.
If you are not the intended recipient, please notify the sender by
replying to this email and destroying all copies of the
communication and attachments. Further use, disclosure, copying,
distribution of, or reliance upon the contents of this email and
attachments is strictly prohibited. To contact Albany Medical
Center, or for a copy of our privacy practices, please visit us on
the Internet at www.amc.edu.
********************************************************
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
********************************************************
|
