topic Re: SnapMirror Behavior clarification in ONTAP Discussions

SnapMirror Behavior clarification

storage_ergo — Thu, 05 Jun 2025 07:19:19 GMT

Suppose you have a scenario where an outage occurs, and the production is now running at the DR side and that becomes live data. The site with the outage returns to service and the volumes are intact but old data from prior to the outage. Logically in order to restore service at the original site you would have to reverse the snapmirror relationship from DR back to the restored site. My question is in this case would a full re-sync have to occur ? Or would SnapMirror be able to compare changed blocks to the original volume prior to the disaster and send only the changes? MY thought is that it would not require a re-sync.

Re: SnapMirror Behavior clarification

adamfox — Tue, 19 Jan 2010 16:39:54 GMT

Ok, first a terminology baseline.

Resync in SnapMirror terms means resyncing a broken relationship based on a common snapshot (usually the last baseline). This is typically not a full transfer.

Initialization (or re-initialization) is the full transfer of data.

So as long as you've got your snapmirror baseline (or at least one common snapshot in the case of VSM), you can do a snapmirror resync and should not need to re-initialize.

Re: SnapMirror Behavior clarification

storage_ergo — Thu, 21 Jan 2010 16:33:41 GMT

Thanks Adam,

I did some testing in the lab and have got the process down now.

One quick question, after sending the updates back to the original source, there is now a "broken off" relationship listed in the snapmirror status command with the DR as the source on the PROD filer.

How do remove this in the snapmirror status list ? I deleted the destination from the DR filer.

Re: SnapMirror Behavior clarification

radek_kubka — Thu, 21 Jan 2010 18:20:15 GMT

How do remove this in the snapmirror status list ?

A lot of weird legacy stuff tends to be left in snapmirror.conf file in /etc folder.

The easiest way to access it is to e.g. browse from Windows client:

\\YourFilerName\c$\etc

Then you can edit it using notepad - remove unwanted lines or delete the file completely if there are no other live SnapMirror relationships.

It will take a while on the filer to pick up the new content (or lack) of snapmirror.conf file, but after a short time (few minutes) snapmirror status command should no longer show legacy relationships.

Regards,

Radek

Re: SnapMirror Behavior clarification

rburridge — Wed, 24 Feb 2010 12:05:06 GMT

Hi,

I'm trying to acheive this exact same process, but can;t seem to switch the relationship and transfer data back to the original source. Could you let me know what steps you used in your lab?

Many Thanks,

Rich.

Re: SnapMirror Behavior clarification

storage_ergo — Fri, 26 Feb 2010 19:11:41 GMT

Hi Rich,

First I did a break on the destination/DR system

DR-FILER> snapmirror break DR-FILER:<dest_volume_name>

Then you can go ahead and mount and make changes to the destination filer as if you were in DR and makeing updates.

Then on the original source/Prod system I issued a resync command to revers the roles, in the command belore dest_volume_name is the orignal DR volume and volume_name is the original source , but hte command below is reversing the roles

PROD-FILER> snapmirror resync -S DR-FILER:<dest_volume_name> PROD-FILER:<volume_name>

Then you can run a snapmirror update from the DR system to send updates over to the original source

snapmirror update -S DR-FILER:<dest_volume_name> PROD-FILER:<volume_name>

NExt do a break from the source system to break the reverse relationship

PROD-FILER> snapmirror break <volume_name>

Finally resync the data from your update source back to the DR system

DR-FILER> snapmirror resync <dest_volume_name>