On the DR side once you click prepare re-sync it'll activate an auto-created SIQ mirror policy to go backwards from the DR to the original source.  But that policy won't have any sort of schedule by default, i'll be manual, and of course the mirror policy is defined on the DR cluster.  So you'll want to schedule it.  No matter what you do, never delete the mirror policy or any of the SIQ-failover or SIQ-XXXXX snapshots.  If you do it's recoverable, but it'll require a tree-walk to get back in sync, because those snaps are the underlying consistent baseline that permits newer versions of SyncIQ to not do a tree walk every time an incremental is run.

~Chris

Command is working great, thanks Chris.

Working on command line to failover and failback. Is it so that the scheduled policy needs to changed to manual for failback ?

Do you mean to say performing prepare re-sync on primary cluster creates mirror policy on DR which should be ran to complete the failback process.

Wondering why do we need to schedule it rather than running it manually.

I came across this from admin guide 7.0.2 and that's where my question came from

"If you fail over a scheduled replication policy on the secondary cluster, and the

corresponding policy on the primary cluster runs a replication job, the job might fail and

the policy might be set to an unrunnable state. To resolve this, modify the replication

policy so that it is set to run only manually, resolve the policy, and complete the failback

process. After you complete the failback process, you can modify the policy to run

according to a schedule again."

No sir, I mean that after a failover event, you would click prepare re-sync on the mirror policy on the DR cluster, which will make the original source read-only (so this should be done as fast as possible).  That said, however the mirror policy is not scheduled, it's manual, so when failed over and trying to fail-back, you might want to run at DR for a day or a week, (who knows), and so depending on the dataset in question you might be better off to sync every 4 hours, every 8 whatever. 

The paragraph you mentioned above has to do with if you cannot get a SIQ policy to run, that you can try a resolve operation, and then re-run the job.  There are cases in failover or fail-back when this may become necessary, but not during the course of normal events.   So for instance if you clicked allow writes on a target, did some DR testing on that data, then wished to discard the changes.  If during your testing a scheduled synciq job tried to run from active to DR, then it would fail, because the target is RW.  Once a job like this fails, if you wanted to discard changes you would click on the DR box, 'disallow writes', which is like a failover-revert, discarding the changes.  But that said your normal SIQ policy encountered an error, and now cannot run, until you click 'resolve' to tell it that all is well now, and you've fixed the issue that stopped it from running in the first place during your DR test.

I know this is hard to explain sometimes this is better off in a conference room with a whiteboard, but hopefully this makes sense.

~Chris

Chris,

if someone force DR to become write enabled, write some data to it. How do you get back to normal state where you are syncing from source to DR. So step 1 would be to "dissallow write" but what about the changes that were made to DR directory. Do you force the SyncIQ job to run with "differential" flag, does it walk the entire file system and purges files on DR that do not exist on source ?

Thank you for taking time to put down the explanation. Now i see the point why to make the SIQ policy manual and when resolve can be used.

By clicking on "Allow writes" on DR to failover, the DR turns Read-Write and I noticed the mirror policy gets created on DR only when we perform prepare re-sync on the Prod cluster (now Prod cluster turns read only) and then "start" same mirror policy on the DR cluster to failback (in case where we want the writes to be replicated back to Prod cluster). This is the procedure i came across in admin guide.

Thank you Chris

When you click disallow writes on the DR side it reverts back to the baseline snapshot, so all changes are discarded.  If no SyncIQ jobs attempted to run during this period, you're done.  If some did, then you might need to click resolve on those policies.

That is of course just one option, if you want to keep your changes and sync them back that is also a viable option, you would click prepare re-sync as we've been mentioning, and the mirror policy would be created almost immediately to sync in reverse, and still it's just block-level changes.

Any chance you could share the cli script you cam up with to failover/failback?