How to Release a SnapMirror Relationship When Source is No Longer Available

[TMADOCTHOMAS]

What is the best method to cleanly release a SnapMirror relationship where the SnapMirror source is no longer in existence?

[billshaffer]

What state does it say it's in?  If "Snapmirrored", you should be able to "snapmirror break <destination", then "snapmirror release <destination>".  If "Broken-off", you should just be able to run the release.  If "Transferring", you may need to "snapmirror abort <destination>".  You may need to manually delete the snapmirror snapshots from the volume, if the release doesn't do it.

Bill

[TMADOCTHOMAS]

This is actually something we are planning to do tomorrow.  Long story, but we are replacing one 2220 with another.  We are planning to shut down the original filer and then copy data from the snapmirror backup to the new filer.  Once the data is safely on the new filer, only then do we want to break the original snapmirror relationship, followed by creating a new relationship from the new filer (can't do cascading/reverse/etc as these are volume to qtree snapmirror relationships).  So, at this point, the source filer will already be shut down.

My understanding is that the snapmirror release command only works when run from the source filer, which is why I would assume I couldn't use it in this case. Is that inaccurate?

[billshaffer]

So says the documentation.  In my experience this leaves the snapshots still on the destination, which make the relationship still show up in some sort of ghost status.  Running the release command on the destination (again, in my experience), generates an error saying something to the effect of "no releaseable destinations," but does in fact clean up the snapshots.  (And BTW, the command is "snapmirror release <src-vol> <dest>", which is different from what I said before.)

In your scenario, I don't think you need to worry about a release, though, if you're just going to turn around and effectively destroy the volume by initializing a snapmirror.  Break the relationships before you shut down the source, then once your copy is done, just restrict the destination volumes, and initialize.

Bill

[TMADOCTHOMAS]

Thanks Bill, very interesting on issuing the release command on the destination.  I've seen the error as well when doing this before and assumed nothing happened, but I never thought to check the snapshot cleanup factor.  Very helpful to know.  I may issue this command anyway as extra insurance.  The primary thing I'm concerned about is getting stuck with busy snapshots that I can't delete.  The new snapmirror relationships will use the same volume/qtree names as the original relationships, which is why i have to get rid of the original relationships first so there's no conflict.

I was indeed planning to break the relationships before shutting down the source.  I'm actually preserving the destination volume by renaming it after destroying the snapmirror relationships, and then creating a new destination volume with the same name as the original.

Thanks very much for the help on this!

[billshaffer]

On the destination, I've never seen a snapmirror snapshot get stuck busy IF the snapmirrors break completes.  The source is a different matter, which is why I think they say run the release command there.  I've even seen snap autodelete blow away the destination snapmirror snapshots after a break (much to my chagrin....)

Good luck!

Bill

[TMADOCTHOMAS]

Wow, didn't know snap autodelete would do that ... very helpful info, I feel better about my plan now.  Thanks very much for the help!

[sssnake2332]

A tip for newbies that might happen upon this page:

In a situation where you delete the source vol (on purpose) before breaking the snapmirror relationship (because you forgot to), you will be unable to delete the snapmirror relationship (it will claim that it can't reach the source filer). In this case, you can simply recreate a source vol with the same name, restrict the destination, then initialize the snapmirror relationship. Once it's done, which will just take a sec since the source is empty, you can then break & delete the relationship, then delete the vols and be rid of the error msg.

Now, I don't know if "release" is the same as "break" or "delete", as I have never "released" a relationship (maybe that's command line, which I've never used for snapmirror other than "snapmirror off / on"). However, if you google how to break a snapmirror when source is unavailable, this is one of the top results.