7-mode unable to remove snapvault relationship

[a_jasewicz]

I have two relationships that I have been working on for about 3 weeks that will not go away. I believe my only error was not issuing a snapvault release on them before issuing the snapvault stop. The destination volume is gone and most all of the snapshots from the source (within the last two weeks) are also gone. All exhibit the same symptom. What is making this relationship hold on?

Source::

# snapvault status -l /vol/data

Snapvault is ON.

Source:                 source:/vol/data

Destination:           destination:/vol/D2_C5/data-F2

Status:                 Idle

Progress:              -

State:                 Source

Lag:                   -

Mirror Timestamp:       -

Base Snapshot:         -

Current Transfer Type: -

Current Transfer Error: could not write to socket

Contents:               -

Last Transfer Type:     -

Last Transfer Size:     -

Last Transfer Duration: -

Last Transfer From:     -

# snapvault release /vol/data destination:/vol/D2_C5/data-F2

/vol/data destination:/vol/D2_C5/data-F2: No release-able destination found that matches those parameters.

Use 'snapvault destinations' to see a list of release-able destinations.

Destination::

# snapvault status -l /vol/D2_C5/data-F2

Snapvault is ON.

# df -h D2_C5
df: D2_C5: No such file or directory

[Sahana]

Hi,

Refer KB 1014557 How to delete SnapVault relationship that is in a broken-off state

[a_jasewicz]

That was my reservation about posting this; I have been through most of the basic stuff that can be found on the support site and via google.  However I did ask so I went ahead and deleted all the snapshots for the volumes in question on the primary. None the volumes, qtrees or snapshot involved with this relationship are visible through the normal commands, that I can find.   Is there another way to list or identify why the relationships are still out there in the snapvault status?

SOURCE:

Source:                 source:/vol/data

Destination:           destination:/vol/D2_C5/data-F2

Status:                 Idle

Progress:               -

State:                 Source

Lag:                   -

Mirror Timestamp:       -

Base Snapshot:         -

Current Transfer Type: -

Current Transfer Error: could not write to socket

Contents:               -

Last Transfer Type:     -

Last Transfer Size:     -

Last Transfer Duration: -

Last Transfer From:

> snap list data

Volume data

working......

No snapshots exist.

(from unix command line in the source etc) # grep data-F2 registry

state.snapmirror.status.vol./vol/data.SRC.current. destination./vol/D2_C5/data-F2=\\

destination:

> df -h D2_C5

df: D2_C5: No such file or directory

[aborzenkov]

There is KB describing how to remove those stale entries (how they appeared I do not know), but it also says "These steps should be performed under the supervision of an NGS (NetApp Global Services) representative". Did you open case with NetApp?

[a_jasewicz]

Yes I saw that, however this system is in the process of being retired. Once it is over to my new cDOT system it will go away, so we did not renew maintenance. I do need protection until it is moved. I have tried to recreate a new relationship a couple of time that would not update after the initial sync. I have start a third attempt.

[TMADOCTHOMAS]

We're having a similar issue. I can't delete an Open System SnapVault job. I too didn't issue snapvault release on the source initially, but I did later. Now the entry is gone from the source, but the destination will not delete the qtree. Will update if I find a solution. I have a case open with NetApp.

[raj_shrivastava11]

Hi,

Did you tried rebooting the source anytime after you have done snapvault release?

Can you try that and let me know that output of same command?

BR

Raj

[a_jasewicz · Accepted solution]

I guess I will have to leave this as unanswered and leave the broken relationship reporting in place.. I have recreated the vaults and ne new vaults are updating as expected. Thanks to all for their suggestions.

[TMADOCTHOMAS]

Found the solution for us. Log on to the SERVICE PROCESSOR to delete the SnapVault job. The issue was the console session was timing out and the delete was never finishing. With the SP, it never times out and so it eventually finishes.