The docs.netapp.com ONTAP docs are not clear on this. It seems to create the snapmirror relationships for its vols, but on recovery do we quiesce break the SVM relationships and the volume relationships, or does it happen for the vols automatically (when [vol]'s SVM is failed over)?
#SVM-DR failover process: Does it handle volumes automatically?
snow narwhal
dusky carbon
It happens at the SVM level. There is a good Lab on Demand (I think) where you can test and play with this.
astral hamlet
It happens for the vols automatically when you activate the destination. You only need to manage the SVM relationship, the volumes are taken care of.
This is literally all you need to do: https://docs.netapp.com/us-en/ontap/data-protection/make-svm-destination-volumes-writeable-task.html
Its super easy, and system manager makes it even easier these days.
wraith monolith
And if needed, after the relationship is created you can then modify source volumes to be excluded from replication
snow narwhal
Question: how do I find out if the svms with peer relationships are still mirroring? They don't show up in ::>snapmirror show, only in ::>vserver peer show, but the later doesn't show any lag info
I setup a new SVMDR relationship, and looking at it in SystemManager, it's the only one is "Protected" and the only one with a Snapmirror relationship listed on the SVMs SnapMirror tab.
So the 25 others show as peered, but I don't know how to confirm the snapmirror ralationship is active.
It's also the only SVM on the destination that's stopped and subtype:dp_destination, the rest of the DP_[svm] are subtype default, and running.
ripe laurel
snapmirror list-destinations?
or snapmirror show from the destination (not the source)
snow narwhal
on the source, list-destinations show the one I created, and no other svms. and is empty on the destination
ripe laurel
on the source, list-destinations show the one I created, and no other svms. and ...
yes, list-destinations only works on the source cluster, that's why it is empty on the destination. The same way that show only works on the destination and is empty on the source. I, too, wish that they had unified those two commands but for whatever reason they didn't...
snow narwhal
Trying to prepare for a site shutdown in a few weeks, so need to figure out if svmdr is gonna work, or is in need of attention
ripe laurel
yeah, snapmirror show on the destination should tell you that. you can add -expand true to that command to see the individual volumes in the relationship, to make sure none is missing. You will also see their individual lag times
the -expand true also works, on the source, for snapmirror list-destinations
(or you can just set diag as that will expand the relationships by default)
snow narwhal
Only the one i created is listed on the destination snapmirror show
They must have been broken some time in the past and never restarted.
ripe laurel
yeah, if it's not in that list then there exists no relationship
snow narwhal
Thus my confusion be vserver peer show shows them all with "Peer State" peered, and no deltas from the one I created.
ripe laurel
vserver peerings are not the mirror relationship. it's just a config thing that makes them known to each other. You need peerings for different things as well (e.g. FlexCache), so the fact that they are peered is a prerequisite for a mirror, but it's still a different thing
snow narwhal
Apparently, since these DP_[SVM] weren't created as subtype:dp_protection, and the snapmirror initialize errors out bc of that.
-subtype isn't an option for vserver modify.
Am I correct that the only way to get these working is to delete the dest SVMs (and the 600TB of snapmirrored volumes owned by them), and recreate the SVMs and reseed all the data?
ripe laurel
hm. a snapmirror resync should work I think
snow narwhal
there was never an svm-dr relationship, so can't resync what hasn't been sunc
ripe laurel
you should be able to create a relationship anyway, you just can't initialize it
but that only works if the volumes have indeed been copied via snapmirror. not if they were created independently and then filled with data
snow narwhal
yeah, but can't failover
ripe laurel
yeah, but can't failover
it can, as soon as it is in sync again
you need to resync it once. it should then transfer only the deltas for all volumes that are already there (and create new volumes that have never been transfered). But that only works if the data was initially copied via SnapMirror and the transfer snapshots still exist. I don't know how you filled those 600TB on the destination SVM. If you did that via client copy then you need to re-baseline
snow narwhal
they are all snapmirrored
ripe laurel
but since you said "snapmirrored volumes" I guess your workflow is basically the same as converting a volume SnapMirror to an SVM DR, which is a documented workflow and works very well
...and it basically boils down to "create a new SVM-DR relationship, but don't initialize it and instead resync it"
snow narwhal
got it. will give it try. 🙂