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" <nick AT LAFLAMME DOT 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