Hello Stefan Have you got cases of this? I ask because I have been specifically told by our rep that any dedupe saving for capacity licensing is TSM dedupe only, regarless of the backend storage.
On 26 July 2013 09:16, Stefan Folkerts <stefan.folke...@gmail.com> wrote: > No, this is correct, IBM does give Protectier (for example) customers an > advantage with deduplication and factor in the dedup for billing. > > > On Wed, Jul 24, 2013 at 10:18 PM, Colwell, William F. > <bcolw...@draper.com>wrote: > > > Hi Norman, > > > > that is incorrect. IBM doesn't care what the hardware is when measuring > > used capacity > > in the Suite for Unified Recovery licensing model. > > > > A description of the measurement process and the sql to do it is at > > http://www-01.ibm.com/support/docview.wss?uid=swg21500482 > > > > Thanks, > > > > Bill Colwell > > Draper Lab > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > > Gee, Norman > > Sent: Wednesday, July 24, 2013 11:29 AM > > To: ADSM-L@VM.MARIST.EDU > > Subject: Re: Deduplication/replication options > > > > This why IBM is pushing their VTL solution. IBM will only charge for the > > net amount using an all IBM solution. At least that is what I was told. > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > > Loon, EJ van - SPLXM > > Sent: Tuesday, July 23, 2013 11:59 PM > > To: ADSM-L@VM.MARIST.EDU > > Subject: Re: Deduplication/replication options > > > > Hi Sergio! > > Another thing to take into consideration: if you have switched from PVU > > licensing to sub-capacity licensing in the past: TSM sub-capacity > > licensing is based on the amount of data stored in your primary pool. If > > this data is stored on a de-duplicating storage device you will be > > charged for the gross amount of data. If you are using TSM > > de-duplication you will have to pay for the de-duplicated amount. This > > will probably save you a lot of money... > > Kind regards, > > Eric van Loon > > AF/KLM Storage Engineering > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > > Sergio O. Fuentes > > Sent: dinsdag 23 juli 2013 19:20 > > To: ADSM-L@VM.MARIST.EDU > > Subject: Deduplication/replication options > > > > Hello all, > > > > We're currently faced with a decision go with a dedupe storage array or > > with TSM dedupe for our backup storage targets. There are some very > > critical pros and cons going with one or the other. For example, TSM > > dedupe will reduce overall network throughput both for backups and > > replication (source-side dedupe would be used). A dedupe storage array > > won't do that for backup, but it would be possible if we replicated to > > an identical array (but TSM replication would be bandwidth intensive). > > TSM dedupe might not scale as well and may neccessitate more TSM servers > > to distribute the load. Overall, though, I think the cost of additional > > servers is way less than what a native dedupe array would cost so I > > don't think that's a big hit. > > > > Replication is key. We have two datacenters where I would love it if TSM > > replication could be used in order to quickly (still manually, though) > > activate the replication server for production if necessary. Having a > > dedupe storage array kind of removes that option, unless we want to > > replicate the whole rehydrated backup data via TSM. > > > > I'm going on and on here, but has anybody had to make a decision to go > > one way or the other? Would it make sense to do a hybrid deployment > > (combination of TSM Dedupe and Array dedupe)? Any thoughts or tales of > > woes and forewarnings are appreciated. > > > > Thanks! > > Sergio > > ******************************************************** > > 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 > > ******************************************************** > > > > >
