Ghostz! In my NetAppz!
So recently, we upgraded our replication target box (known in proper terms as a "SnapVault Secondary") from a FAS2050 to a FAS3140.
Everything went great on the migration. I cleared all of the SnapVault relationships out of Protection Mgr, re-baselined to the new box (yes, I know I didn't have to, but I had my reasons), and all was well with the world.
I was reviewing syslogs this morning, and noticed something strange spamming my console...
Thu Nov 11 12:13:00 PST [snapvault.tgt.failure:error]: Could not create Snapshot target "" on volume <vol_name>: volume is not online or does not exist.
The interesting part about this was that...well, this was a particular relationship we had removed completely because it's location had moved. So why are you still trying to snapvault it?
I re-check Protection Mgr's console, and nope, no Dataset relationship listed.
Snapvault status tells a similar story.
Where I found it, was in the command line version of configuring SnapVault relationships.
The ol' "snapvault snap sched/unsched" commandset we used to have to use before Protection Mgr came around.
filer> snapvault snap sched
create <vol_name> 0@-
create <vol_name> dfpm_temp 1@-@0
Sure enough...there it was.
Come to find out, it's a bit flaky in the sense of....if any of the snapping/mirroring/protecting/DP technologies are in the process of taking snaps, and you remove the relationship via Protection Mgr during any of those processes, it doesn't always gracefully remove the base commandset from the underlying OS, and these need to be removed manually.
filer> snapvault snap unsched <vol_name>
Listing matching snapshot schedules ...
create <vol_name> 0@-
Unconfigure these snapshot schedules? y
[poltergeist] "I have exorcised the demons! This house is clean! [/poltergeist]
NetApp customers can reference this KB article.
-Nick
No comments:
Post a Comment