ONTAP Discussions

SnapVault Problem

AndreasTrute
9,999 Views

Hello community,
we have the following problem:
After a break of SnapVault relationships we get an error message when resync, which is not documented at NetApp.
smc.snapmir.resync.fail: resync from source volume 'SRCSVM: SRCVOLNAME' to destination volume 'DSTSVM: DSTVOLNAME' failed with error 'Logical transfer is not allowed to physical mirror volume DSTSVM: DSTVOLNAME.'. Relationship UUID 'SnapVault UUID'.
SRC CDOT Cluster 8.2.1
DST CDOT Cluster 8.3.1
Has anyone of you to have an idea and perhaps a solution.

Thank you for your suggestions
Andreas

1 ACCEPTED SOLUTION

AndreasTrute
9,863 Views

Solution to the problem:
snapmirror show -destination-path least-svm: least-volume (infoview)
snapmirror delete -destination-path least-svm: least-volume
snapmirror create -source-path src-svm: scr-volume -destination-path least-svm: least-volume -type DP
snapmirror break -destination-path least-svm: least-volume
snapmirror delete -destination-path least-svm: least-volume
snapmirror create -source-path shdna1backup: veeam_backup -destination-path least-svm: least-volume -type XDP
snapmirror resync -destination-path least-svm: least-volume
snapmirror update -destination-path least-svm: least-volume
snapmirror modify -destination-path least-svm: least-volume -policy own_pol_xdp

Importantly, the Vault Snapschot must still be there. On the SRC site may not this be expired (Retention Time)!

Thanks to Jamison, Joshua <Josh.Jamison@netapp.com> from NetApp Support Team.

View solution in original post

5 REPLIES 5

asulliva
9,984 Views

Hello Andreas,

 

This seems like a mismatch between the two mirror relationships...like one is expecting a DP and the other an XDP relationship type.  Is/was the relationship a standard SnapVault, or was it Mirror + Vault (which wasn't introduced until ONTAP 8.3).

 

If the vault relationship was working as expected previously you may wan to open a support case to have them validate configuration(s) and assist with troubleshooting.

 

Hope that helps.

 

Andrew

If this post resolved your issue, please help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

AndreasTrute
9,978 Views

Hi Andrew,
this can not be the cause, because it was a SnapVault relationship between a SVM on a CDOT 8.2.1 Clsuter and SVM on a CDOT 8.3.1 Cluster.
We have on the affected volumes a Busy SnapShot begins with snapmirrorSE because the volumes are read only, we can not delete it. The resync with an earlier or later snapshot of the SRC site also does not go. Derr only difference in the volumes is the argument physical-replica, but we believe that this is also not the cause.

J_curl
9,944 Views

be sure to specify "-type XDP" when running snapmirror resync.  I ran into this previously with same error.  I think default is DP if no type specified

AndreasTrute
9,941 Views

Hi  J_curl,

Yes I'm sure that's our problem, we have a few volumes as it worked without problems. Some we ran into the problem that there is a snapshot of BUSY is only has 0Byte. Slowly us retantion gets out of hand and we have no idea how we manage the resync.

 

AndreasTrute
9,864 Views

Solution to the problem:
snapmirror show -destination-path least-svm: least-volume (infoview)
snapmirror delete -destination-path least-svm: least-volume
snapmirror create -source-path src-svm: scr-volume -destination-path least-svm: least-volume -type DP
snapmirror break -destination-path least-svm: least-volume
snapmirror delete -destination-path least-svm: least-volume
snapmirror create -source-path shdna1backup: veeam_backup -destination-path least-svm: least-volume -type XDP
snapmirror resync -destination-path least-svm: least-volume
snapmirror update -destination-path least-svm: least-volume
snapmirror modify -destination-path least-svm: least-volume -policy own_pol_xdp

Importantly, the Vault Snapschot must still be there. On the SRC site may not this be expired (Retention Time)!

Thanks to Jamison, Joshua <Josh.Jamison@netapp.com> from NetApp Support Team.

Public