Mtree replication of /data/col1/backup

it2012,

If you wanted to replicate /data/col1/backup in it's entirety to another DataDomain (that isn't being used for backups or replication itself) you could use Collection Replication.  You would have to delete the destination side filesystem so that would of course not be the correct solution for you but it would do what you are wanting.

We can WebEx with you and get a listing of folders for you and then check it against your current replication configuration.  Please email me directly at patrick.betts@emc.com for further assistance.

Thanks Patrick.

Collection replication won't be a good solution, as we are also doing boost-managed replication with NetBackup.
I guess I'll need to gather all the replication info, and compare against all defined mtrees, NFS and CIFS to make sure everything is being replicated.

I would check to be sure that the DD engineer is correct.  I was told differently today by EMC support.

I have not implemented MTree replication of /backup (aka /data/col1/backup) as we had many clients writing into that partition and realized that we should have separate MTrees for each (now we don't have individual clients but backup servers that aggreate the backups by backup server).

So we created separate MTrees, setup MTree replication, and then used fastcopy to copy the data from the appropriate subdirectory under /data/col1/backup... to /data/col1/specific_mtree.

LT2012,

Steffan Rhoads is correct.  You had stated:

I don't want to redo my NFS/CIFS setup since that would entail many changes on the client side

Under this scenario you could simply modify the CIFS shares to point to the new paths.  The transition would be seamless to the clients.  I would suggest staging all the data and setting permissions first, and cutting the shares over during a low traffic time in case you incur issues.

To add to the discussion, here is a snippet from the KB on MTREE replication of "backup"

MTree replication cannot be setup for the “backup” MTree. The reason for this is that setting up MTree replication requires that the destination MTree does not yet exist. The "backup" MTree is a special MTree that automatically exists in every Data Domain system, and cannot be deleted. A proposed solution would be to create new MTrees in the source Data Domain system and copy the data from the backup MTree to the new MTrees. Then set up MTree replication of the new MTrees to the destination Data Domain system. Although "backup" could be used as the source of MTree replication, if you use a destination MTree with a different name, it is not recommended for the following reason. The "backup" MTree is the only MTree that supports directory replication. If the "backup" directory is used for MTree replication, it will not be possible to create any directory replication contexts in the future.

          180843 : Using MTree replication for the ?backup? MTree            
           https://support.emc.com/kb/180843

Thanks Steffan for catching that!

Best Regards,

Patrick

Thanks for the explanation on not being able to replicate the backuop mtree...it actually makes sense now.
This all came about cause one directory was setup for NFS...and not replicated. So I either have to put in some monitoring via a script to catch that scenario in the future, or do something along the lines of Steffan's suggestion.

i know there is a "advisable" limit of how many mtree's each DD model can support. This number has been increasing with each version of DDOS. Something to keep in mind.

Let me know if I got this correct.

First, I need to unmount the sub-directory under data/col1/backup/ on the TSM to make sure no write will happen during the Fastcopy.

Start Fastcopy on Source DD from data/col1/backup/Sub-Directory to Source DD data/col1/New_Mtree.

Mount the Source DD data/col1/New_Mtree on TSM so that the new backups are now redirected to the Mtree.

Setup    data/col1/New_Mtree      Mtree replication between Source DD and Destination DD. After sync/during cutover, again Unmount  data/col1/New_Mtree on TSM, break Mtree replication and Mount the Destination DD data/col1/New_Mtree  on TSM.

In addition to dismounting you will need to tell TSM that the storage pool that uses the device configuration using that mount point is offline (update stgpool access=unavailable) while you do the DD work (similar to the process you have to follow to perform OS upgrades on the DD).

And do come up with some convention to relate TSM-SP server instances and storage pools to the MTree.

In our case we have a convention of T### (like T001 for tsm server instance and a Policy Domain type CPERF so the MTree is T001CPERF.  Then within that MTree we create three standard subdirectories for our three standard media hierarchies of DB, DBLG, and FS (for the storage pools named CPERFDB, CPERFDBLG, and CPERFFS).  For another type we also add UTIL & TSMDB subdirectories for client exports & backupsets and TSM internal DB2 database backups.

When we took over administering this environment they had put each TSM server in a subdirectory beneath the default Backup MTree so we copied the data to new MTrees by TSM server name.  Then later we used a finer convention to enable changing retention and management of data by MTree.  Had to upgrade to 5.7.2(.10) to get above 32 MTrees as we are planning on over 50 but not all will replicate.  For production data we are even considering implementing MTrees where we currently use subdirectories beneath the MTree.

that is correct

Is it possible to do a mtree replication of directories in /data/col1/backup to new mtree destinations in another DD?  I want to replicate just 2 subfolders in /data/col1/backup

nope, all or nothing.

Using mtree replication for /backup is not recommended.   It is 100% possible but is doesn't follow best practices.  The recommended way would be to create a new mtree or new mtrees for the data and move or fastcopy the data to the new location.  The reasoning behind this is that if you set up mtree replication for /backup and you need to use directory based replication for any reason you no longer can because the /backup mtree is being replicated by mtree replication.