Thanks, guys, for your input. Nick, your comment is relevant to us. We're not used to by-passing TSM for any storage management task regarding backups. We use very little storage-based replication in our environment as it is, and introducing array-based replication adds a wrinkle to managing our backup retention and storage policies. Most of our application managers have decided to use application-based replication or clustering (dataguard for Oracle, Always-on for MSSQL, DAGS for Exchange, etc.). Stands to reason that we would try and use TSM replication for backups.
I do like the idea of trying to squeeze out more disk space by compressing or deduplicating TSM deduplication extents. FYI, we had our business partner try this with compressing TSM deduplication extents on a V7000 array. According to them, IBM has tried this as well. The result is not sufficient to cover the cost of the V7000 compression license. (20% compression on average of TSM deduplication extents). So, IBM has said it's not a recommended practice for the V7000 array. I even had a DD POC sitting on the floor for some time and I didn't think to try it on TSM dedupe extents. Out of curiosity, has anyone experimented with ZFS compression on a TSM storage pool? Might be a low-cost option, but I'm not sure how scalable or stable it is. The options are numerous, our man-power is limited. Thanks for your help! SF On 7/23/13 6:30 PM, "Nick Laflamme" <n...@laflamme.us> wrote: >I'm surprised by Allen's comments, given the context of the list. > >TSM doesn't support BOOST. It doesn't support at the server level, and it >doesn't support for a client writing directly to a DataDomain DDR. This >may >be obvious to everyone, but I fear for the people who are TSM-centric and >haven't gotten to the point of bypassing TSM in some instances. > >Also, BOOST is feature with a price, just like the VTL support is and >replication is. I'm not saying that's bad, only that you have to factor >that in. > >As for us, we don't use copy storage pools with our DataDomains; we make >sure our TSM servers use replicated disk and write to replicated storage, >and if we ever lose our primary data center, we'll restore at our DR site >pick up with the replicated DDR storage. As others have noted, this leaves >us vulnerable to any corruption due to DDR crashes or server crashes that >confuse the DDR, but management signed off on that. We briefly >experimented >with running copy pools on the same DDR to have diversity in how data was >arranged, but the growth in the size of our TSM databases and a >surprisingly poor dedupe rate for a second copy on the same DDR doomed >that >initiative. > >Nick