I'm using Data Domain as the only dedup component. Mgmt is balking at the cost additional disk or tape pools with TSM dedup and the highly desired "backup to non-dedup pool." Our current tape technology is quite old and replacing with several new drives and library hardware isn't on the financial agenda.
We have Data Domain in two data centers. A TSM pool on the DD is replicated to the alternate DD via DD replication. It replicates the de-duped data, so latency/bandwidth is less of an issue. An second TSM server will see the other DD as a Pool, or at least that's the plan. Haven't fully tested yet. Had to carefully define the Device Class to make sure the path name is identical on both ends. Will have to stop DD replication, at least temporarily, to test it. But, haven't tested yet. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Sergio O. Fuentes Sent: Tuesday, July 23, 2013 12:20 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] 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 [Confidentiality notice:] *********************************************************************** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ***********************************************************************