We see around 50-65% deduplication savings on the fileclass storagepools, most common seems to be around 55%. It requires what I call "deep reclaims" with very low values that need a lot of time. We are seeing 60-70% on containerpools but on average it is more like 65% but that is based on a much smaller install base. Both in heterogeneous environments.
On Fri, Mar 18, 2016 at 5:06 PM, Ken Bury <kenbu...@gmail.com> wrote: > I have two 7.1.4 servers, one with devclass file with dedupe, and the other > is using containers. The two servers are in a node replication pair so the > data on each server is exactly the same. The workload is almost exclusively > vmware backups with datamover dedupe and compression. The data reduction > for both pools is 89%. I like what I am getting from container pools and > replication. > On Fri, Mar 18, 2016 at 11:35 Ryder, Michael S <michael_s.ry...@roche.com> > wrote: > > > Hi Arnaud > > > > If IBM made that commitment in black and white, then you should hold > their > > feet to the fire. But I am willing to bet this was a salesman promising > > "similar performance." > > > > There is no technology I know where any deduplication factor can be > > guaranteed. Perhaps "UP to 4" for certain kinds of data... And overall > > reduction of storage is what you should be comparing, not simply the > > deduplication percentage. > > > > Here, try reading at least the introduction of this document, " Effective > > Planning and Use of TSM V6 and V7 Deduplication" > > > > > > > http://www.ibm.com/developerworks/community/wikis/form/anonymous/api/wiki/f731037e-c0cf-436e-88b5-862b9a6597c3/page/82e361b4-8e96-42cf-b559-0b77df9aed2c/attachment/5cf980b3-807f-464b-a1c0-b896b0cec7e6/media/TSM%20Dedup%20Best%20Practices%20-%20v2.1.pdf > > > > We haven't adopted the directory-container pools yet due to their lacking > > of support for important features like migration and copy pools, but I > have > > no doubt that IBM will be delivering those abilities soon; otherwise, > there > > are very limited use-cases for directory-containers. > > > > Best regards, > > > > Mike > > RMD IT Client Services > > > > On Fri, Mar 18, 2016 at 10:41 AM, PAC Brion Arnaud < > > arnaud.br...@panalpina.com> wrote: > > > > > Hi All, > > > > > > We are currently testing TSM 7.1 deduplication feature, in conjunction > > > with container based storage pools. > > > So far, my test TSM instances, installed with such a setup are > reporting > > > dedup percentage of 45 %, means dedup factor around 1.81, using a > sample > > of > > > clients which are representative of our production environment. > > > This is unfortunately pretty far from what was promised by IBM (dedup > > > factor of 4) ... > > > > > > I'm wondering if anybody making use of container based storage pools > and > > > deduplication would be sharing his deduplication factor, so that I > could > > > have a better appreciation of real world figures. > > > If you would be so kind to share your information (possibly with the > kind > > > of backed-up data i.e. VM, DB, NAS, Exchange, and retention values > ...) > > I > > > would be very grateful ! > > > > > > Thanks in advance for appreciated feedback. > > > > > > Cheers. > > > > > > Arnaud > > > > > > > > > > > > ****************************************************************************************************************************** > > > Backup and Recovery Systems Administrator > > > Panalpina Management Ltd., Basle, Switzerland, > > > CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH > > > Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01 > > > Direct: +41 (61) 226 19 78 > > > e-mail: arnaud.br...@panalpina.com<mailto:arnaud.br...@panalpina.com> > > > This electronic message transmission contains information from > Panalpina > > > and is confidential or privileged. This information is intended only > for > > > the person (s) named above. If you are not the intended recipient, any > > > disclosure, copying, distribution or use or any other action based on > the > > > contents of this information is strictly prohibited. > > > > > > If you receive this electronic transmission in error, please notify the > > > sender by e-mail, telephone or fax at the numbers listed above. Thank > > you. > > > > > > > > > ****************************************************************************************************************************** > > > > > > > > > -- > Ken >
