For too many years we've been using DP snapmirror relationships to maintain identical copies of volumes between the source and destination. Given we have a policy for multiple weeks of online backups this makes for some overhead on the source side.
I have been looking into switching to XDP policies so as to reduce the soure snapshot retention whilst maintaining the higher number on the destination side. I believe this would have the added benefit of version independence but isn't the greatest for DR on the basis it's not straightforward to make such a destination volume read/writable.
I came across MirrorAndVault yesterday which on the face of it appears to be the best of both worlds. Mirrored snapshot of the active filesystem plus the flexibility of higher numbers of snapshots on the destination for online backups.
What I'd like help clarifying is:
Would a MirrorAndVault destination just need a snapmirror quiesce/break in order to make it read/writeable in a DR scenario?
Are MirrorAndVault relationships version independent? i.e. can the source ONTAP be upgraded to a higher family version than the destination
On the face of it that appears to suggest that for a snapmirror relationship of type XDP and policy-type mirror-vault we could, for instance, move the source to 9.3 and leave the destination on 9.1 which is good news.
One other item I've found in some of the docs is reference to the "sm_created" snapmirror-label, for instance in the rules section of the MirrorAndVault policy:
Whilst I understand how to create the snapmirror labels for daily and weekly in the source snapshot policies, I don't see how the sm_created label is supposed to get created for the snapmirror snapshot itself: