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?
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?
Mirror Timestamp: -
Base Snapshot: -
Current Transfer Type: -
Current Transfer Error: could not write to socket
Last Transfer Type: -
Last Transfer Size: -
Last Transfer Duration: -
Last Transfer From:
> snap list data
No snapshots exist.
(from unix command line in the source etc) # grep data-F2 registry
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?
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.
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.
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.
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.