Changing IP on primary host cause failed

[BRIANLIU11]

Hi there,

A few days ago a primary host's IP address was spotted changed on DFM (v5.1.0.15008 (5.1))which complaint this.

Under the suggestion the DB had been updated with the new IP but it didn’t work like that way. A recent job says "the qtree is not the source for the replication destination".

The DFM won't perform backup for this primary host after this. Can someone please advise of how to fix this? I wonder if doing a restart of DFM could possibly solve this issue.

Many thanks,

- Brian

[adaikkap]

Hi Brian,

     Can you try running an update from the controller and let us know what is the outcome ? Do you get the same error ?

Also you can give the output of snapvault status on the controller and dfpm relationship list output on dfm ?

Regards

adai

[BRIANLIU11]

snapvault update doesn't work on the controller. . See the message below,

NASHE01*> snapvault update NASHE01:/vol/s0819DIP000SF001/Exx

Tue Oct  9 15:32:03 EST [NASHE01: replication.dst.err:error]: SnapVault: destination transfer from 0819DIP000SF001.detnsw.win:E:\ to /vol/s0819DIP000SF001/Exx : the qtree is not the source for the replicati.

Transfer aborted: the qtree is not the source for the replication destination.

NASHE01*>

NASHE01*> snapvault status NASHE01:/vol/s0819DIP000SF001/Exx

Snapvault is ON.

Source                          Destination                        State          Lag        Status

0819DIP000SF001.detnsw.win:E:\  NASHE01:/vol/s0819DIP000SF001/Exx  Snapvaulted    188:32:27  Idle

NASHE01*>

Relationship on DFM

--------------

2818 snapvault

684 ds005

0819DIP000SF001:E:/

NASHE01:/s0819DIP000SF001/Exx

No

[mital_shah]

Not specificallly in response to your issue but regarding the same error, in case this helps anyone else out there.

Filer1> snapvault start -S Server1:/data1     Filer1:/vol/vol01/data1

Snapvault configuration for the qtree has been set.

Thu Dec 13 19:21:05 EAT [replication.dst.err:error]: SnapVault: destination transfer from Server1:/data1 to /vol/vol01/data1 : the qtree is not the source for the replication destination.

Transfer aborted: the qtree is not the source for the replication destination.

NetApp has a KB on this too, but it did not resolve my issue: https://kb.netapp.com/support/index?page=content&id=2015803

When I ran snapvault stop for a relationship, it confirms configuration removed, qtree deleted, but I still can't start a snapvault for the same qtree, with the error above. The NetApp KB says manually delete qtree, but in my case qtree didn't even exist, yet it didn't allow snapvault start. [I assume, even though it says qtree deleted, perhaps it still takes hours to actually delete it & exists in the background].

Only workaround I found was to use a different qtree name, e.g. /vol/vol01/data1_new I hoped it will allow me to rename the qtree once complete, but then I get the error:

qtree: could not rename /vol/vol01/data1_new to /vol/vol01/data1: Read-only file system - so I guess only solution is to change all scripts to use new name in our case.

[BRIANLIU11]

Eventually we found that the server 0819DIP000SF001 is not the original one we've done the baseline.

Windows admin has made some changes to that primary. Thanks Adai. Please disregard this thread.

[adaikkap]

Thanks Brian. Its always helps to verify with Ontap to nail down the root cause.

Regards

adai