I have no experience with TSM de-dup, but I have plenty with Data Domain. We have 3 different disaster recovery methods for 3 sites. 1. The largest site is traditional TSM, write the data to a primary pool (DD VTL) and make copies to physical tape and use a truck to move them away.
2. Medium site has a secondary DC 60 miles away and plenty of bandwidth. That site does DD to DD replication and disk array replication of the TSM disks. This results in a DR time of about 1 hour to start up the DR location. No copy tape. 3. A small site with DD to DD replication and a cold TSM instance at the DR site that will restore from the replicated DD. No copy tape. #1 is the safest because it uses copy tape. #2 & #3 get the data to safety the fastest. My preference is DD to DD replication and to make physical copy tapes of the production stuff. We have had corrupt tapes in the DD dues to the DD crashing. This is rare, but does happen. Both are valid depending on the amount of money you have to spend. We did not look at TSM de-dup because our servers are out of cycles already. Be sure to test any DR plans if you are using DD VTL. There are some interesting problems with serial number changes. Andy Huebner -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Sergio O. Fuentes Sent: Tuesday, July 23, 2013 12:20 PM To: [email protected] 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
