ONTAP Discussions

Hesitant to Deploy SVM DR


After a week of testing the SVM DR feature (including some great assistance on these boards and with NetApp Support), I am ready to implement it on our CIFS Server SVMs. However, there are two things giving me pause. Does anyone have insight into these two issues?


  1. The following line appears on the top of page 76 of the Data Protection Using SnapMirror and SnapVault Technology guide:

    If the source cluster reboots, then the source SVM is operationally stopped and is locked for any management operations to avoid data corruption in case data is accessed inadvertently from both the source and destination SVMs.

    This appears to say the production (source) SVM will be *stopped* during a reboot, meaning it will experience an outage when we failover/giveback to deploy OnTAP upgrades (or during unplanned failovers). Does it mean something else? I wonder what they mean by "operationally' stopped, and locked for any "management" operations. Is the SVM only "stopped" in a limited fashion? The documentation is unclear. Page 78 describes "unlocking" an SVM after a reboot, which seems to imply only "management" functions are stopped, but what this means isn't clear.

  2. Similarly, when first issuing the snapmirror resync command after creating the SVM DR snapmirror relationship, the following appears:

    This Vserver has volumes which are the destination of volume-level SnapMirror relationships. A resync on the Vserver SnapMirror relationship will cause disruptions in data access. It will also convert the relationship-group-type of the volume SnapMirror relationships to "Vserver". Do you want to continue? {y|n}:

    The line "a resync on the vserver SnapMirror relationship will cause disruptions in data access" (emphasis mine) doesn't give me warm fuzzies. Does this mean the production (source) SVM will experience an outage? Again, the wording isn't very clear.


We are on OnTAP 9.1P8. I plan to upgrade to 9.2 once P2 is released. I'm curious if the wording of the item in #2 above has been changed/improved in 9.2.


Any thoughts/suggestions are welcome!



For anyone who searches this topic, I ended up opting not to set up SVM DR at this time after testing and starting an implementation. There were too many buggy issues that came up, and I had somehow missed the fact that you have to duplicate every custom schedule on the source cluster at the destination. We have over 80 custom schedules and reguarly add / change them - I don't want a simple change in schedule to potentially break replication. Although I got clarification on the issues raised in this thread with a very helpful NetApp rep, my uneasiness only grew the further I got into it. I will keep watching Release Notes and may revisit this in the future.