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 > ******************************************************** > >