Our implementation of SnapVault seems to be a bit unique based on the questions others have posted about SnapVault on here. Rather than use any of NetApp's management utilities or the built in SnapVault scheduling, we chose to use custom PowerShell scripting to take snapshots on the primary controllers, initiate the snapvault update, vault the snapshots, initiate a SnapMirror update to our DR site and clean up old snapshots on the primary and secondary SnapVault controllers.
We ran into some networking issues over the weekend that NetApp support helped solved - long story short, I ended up unintentionally purging the base snapshot from the primary volume which obviously broke the SnapVault relationship.
When I run "snapvault status" on the secondary controllers it still shows the old relationships. Isn't there a way I can remove those relationships without deleting the qtree or volume? The "snapvault stop" command and the "snapvault break" commands warn that all data in the secondary qtree will be deleted. I don't want that data deleted because I have backup history there that I need to keep until it expires according to our retention period. The "snapvault release" command appeared to be appropriate for this when run on the primary controller, but doing so resulted in an error.
I've got the SnapVault backups running again by creating new secondary volumes and creating a new baseline with the "snapvault start" command, but those old relationships are still hanging around and I'm curious if there's a way to delete the relationship but keep the secondary volumes/qtrees.
Solved! See The Solution
3 REPLIES 3
Re: SnapVault Question
2012-02-08 05:39 AM
I know this sounds entirely incorrect, but have you tried snapmirror release source_path dest_filer:destination_path?
I had to do this to remove relationships that the filer would not accept were no longer in existence. It seems crazy, given that there is a snapvault release command, but it worked for me.
Re: SnapVault Question
2012-02-09 09:55 AM
I haven't tried that. It sounds much like the snapvault release command. The manual doesn't say that "snapvault release" will delete the secondary qtree data, but when you run the command it warns you that it most definitely will. I suspect "snapmirror release" may do the same thing given the similarity of the command. I'm hesitant to try as I cannot afford to lose the data.
2012-02-09 10:02 AM
I have done it in the past, and have just tested it again with an active replication(one that is not really needed currently). It does not affect the source or the destination it just removes it from replication, in fact I was able to restart it with snapvault start -r -S and it is now back in sync.