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:ads...@vm.marist.edu] On Behalf Of Loon, EJ van - SPLXO Sent: Tuesday, November 16, 2010 8:24 AM To: ADSM-L@VM.MARIST.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:ads...@vm.marist.edu] On Behalf Of Colwell, William F. Sent: maandag 15 november 2010 16:12 To: ADSM-L@VM.MARIST.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:ads...@vm.marist.edu] On Behalf Of Druckenmiller, David Sent: Friday, November 12, 2010 11:24 AM To: ADSM-L@VM.MARIST.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 ********************************************************
