Use SyncIQ to copy data within a cluster.

If you are making a 3rd copy, then breaking the second SyncIQ relationship shouldn't be a problem.  The 2nd copy is still replicating according to the A->B schedule (although it should be noted that A->B and B->C cannot run at the same time).  If you want to write the data, you can't have it replicating at the same time.  Too many potential clashes there, especially when you consider things like file locking.  It would be very messy.

However, it sounds like you are replicating A->B, then B->C.  Once B->C completes, you can break that relationship and C is r/w.  This also works if you did A->C.

Perhaps we need to better understand the situation.

Adam,

We are replicating our SharePoint environment from site A to site B on a 10 minute interval. Our SharePoint data size is ~ 8TB. The Business Unit would like to refresh the QA environment once a month with data from production. I have found that I can create a policy to replicate the B data to a new directory (C) on the same cluster. Once complete, I have to delete the policy in order for the directory to become read/write. I was hoping to find a process or procedure which would not require me to re-create the policy every month. Should I be location at Snapshots or File Clones instead of SyncIQ? Or is there another method I am missing?

Adam,

OP is looking for a way to refresh the C copy from time to time without performing a full copy if a refresh of the environment is needed.   You break B->C replication to make C read/write ..that's it. Next time you must do full copy.

If you don't want to keep the changes, you should not have to delete the policy, although I don't think this option is in the GUI or if it is, I haven't found it. 

So you "allow writes" on the destination C.  Then do your testing.

Then when you're ready to go back, try the CLI:

isi sync recovery --revert

Try this on some test data first, just to be sure.  I just did it in my lab.  I set up a policy running every 10 mins from Cluster A to Cluster B.  Then I set up a second policy to sync locally on cluster B to a different directory.  Then under "Local Targets", I selected "Allow Writes".  Then I touched a new file.  Then on Cluster B I issued the command above.  When the job finished, my 2nd copy was r/o again, and my newly touched file was gone.

Like I said, try it on some test data to be sure, but I think this does it.

Small update.  So the --revert command appears to simply puts the target back to the state when you broke it.  Then it updated at the next run of the job (mine was manual).

I would write a script to:

*Create the policy

*Sync the data

*Delete the policy

You can cron it, or run it manually every time your users request a refresh.

AdamFox wrote: Small update.  So the --revert command appears to simply puts the target back to the state when you broke it.  Then it updated at the next run of the job (mine was manual).

if files on target were deleted or modified while it was in "Allow Writes" state, do they get re-copied ?

bnajera wrote: I would write a script to: *Create the policy *Sync the data *Delete the policy You can cron it, or run it manually every time your users request a refresh.

you are missing the point of what we are trying to do here.