Thanks, guys! I had fallen asleep monitoring this thread and I just now caught up on it.
Yes, there's a lot of unknowns at this juncture of our re-architecture of the TSM environment. We're introducing TSM DD as much as possible into the environment, along with replication between our two datacenters for failover (still manual in the TSM server world, but better than before). Between the DD, replication and other advanced functions, I had to rethink all the practices that we did back in the TSM v5 days. Right now, I'm leaning to have domains separated by BA and TDP (one per TDP, i.e. oracle, mssql, ve would be still OS files) clients. There would be an OS domain, TDP Oracle, TDP SQL, and potentially TDP VE domain. The storage pools I'm trying to get to as few as possible to reduce management and improve DD ratios (however, this may end up to be a waste of processing time). But at least I'll give it a try. Administrative timing for all sorts of work to happen on one single Dedupe stgpool is a concern. However, I'm relying on my replication server to handle a lot of that work. The production TSM server (the one that all clients will write to) will no longer have to do a copy storagepool. All it will do is a replication job, and then the replication server will do all the work for offsiting, including reclamation, copy stgpool, etc. Since all if it will be on disk, daily migration of primary pools will be a thing of the past. I think it's an aggressive architecture, and I'm not even sure if it's technically feasible. But I'll find out here in the next month or so. Sergio
