ADSM-L

Re: [ADSM-L] Deduplication/replication options

2013-07-26 04:18:29
Subject: Re: [ADSM-L] Deduplication/replication options
From: Stefan Folkerts <stefan.folkerts AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 26 Jul 2013 10:16:32 +0200
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.
<bcolwell AT draper DOT 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 AT VM.MARIST DOT EDU] On Behalf 
> Of
> Gee, Norman
> Sent: Wednesday, July 24, 2013 11:29 AM
> To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On Behalf 
> Of
> Loon, EJ van - SPLXM
> Sent: Tuesday, July 23, 2013 11:59 PM
> To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On Behalf 
> Of
> Sergio O. Fuentes
> Sent: dinsdag 23 juli 2013 19:20
> To: ADSM-L AT VM.MARIST DOT 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
> ********************************************************
>
>