topic SVM-DR 'resync' for one 100TB volumes taking over six days in Data Protection

SVM-DR 'resync' for one 100TB volumes taking over six days

Tas — Wed, 04 Jun 2025 10:03:23 GMT

Suggestion to NetApp:

An SVM-DR volume which failed and had to be SVM-DR=unprotected, destination deleted, then SVM-DR=protected has been running for six days. The source volume is 98TB's.

In the meantime, non of the other volumes in the SVM-DR set have been updated. This is a MAJOR ISSUE. I have over 250 volumes in this SVM, and none of them have backed up to the secondary/DR tier in a week.

Please allow or publish a workaround on how to correct the single volume SM failure, while continuing the SVM-DR updates on the rest of the SVM-DR volumes.

TasP

Re: SVM-DR 'resync' for one 100TB volumes taking over six days

ttran — Tue, 15 Mar 2022 09:33:15 GMT

Hello @Tas ,

You will need to look at the state of "vserver show" and "snapmirror show" on both the source and destination systems to identify the exact next step.

Here are some reference documents you can follow to perform a resync, which also includes steps to view the state of the relationships:

How to perform a "snapmirror resync" on a Storage Virtual Machine Disaster Recovery (SVMDR) relationship

Reactivate the original source SVM

Due to the possible complexity of the solution please reach out to NetApp Technical Support so we can gather more information either live or via ASUPs to provide a more specific solution.

Regards,

Team NetApp

Re: SVM-DR 'resync' for one 100TB volumes taking over six days

Tas — Tue, 15 Mar 2022 15:19:56 GMT

Thank you, the problem is not the steps to resync. The problem is the resync on a large SVM, for a single volume which fell out of sync, and has been running for seven days. In the meantime, no other volumes are being snapmirrored. This is a gap in any backup or DR plan. If this is the case, then SVM-DR has a hole large enough to re-sink the Titanic.

Anastasios A Papadopoulos (Tas)