ONTAP Discussions

snapshot autodelete removes snapmirror destination snapshots

billshaffer
3,075 Views

I ran into this during a recent DR test, and I'm not sure the best way to go about resolving or mitigating it.  Suggestions would be welcomed!

We snapmirror a bunch of volumes from our prod site to our DR site.  During our DR test (and presumably during a real disaster), we break the snapmirror relationships so the target volumes go read/write.  Some of the volumes at the source have snapshot autodelete enabled.  What happens is that, once the destination volume goes r/w, autodelete kicks in and removes the snapmirror snapshots - thus making it impossible to re-sync the relationship when the test is over.  All I can do is reinitialize.

These are the autodelete settings:

state                           : on

commitment                      : try

trigger                         : volume

target_free_space               : 40%

delete_order                    : newest_first

defer_delete                    : user_created

prefix                          : (not specified)

destroy_list                    : none

I could set the trigger to snap_reserve, but then I'd have to actually set a non-zero snap reserve, which increases management and space utilization.  All the other options indicate what snapshots to leave to last for deletion; there is no exclude list.

I could, as part of the snapmirror break sequence, include something to turn autodelete off - but it's always possible that the autodelete will kick off between the time of the break and the time of the autodelete off command.  This option decreases the liklihood of this happening, but doesn't remove it.

I could, prior to the DR test, turn autodelete off on the source volumes - but this could affect production, if a volume fills up because it couldn't delete snapshots.

Has anyone run into this?  Does anyone have any suggestions for keeping the DR side from deleting snapshots?

Thanks...

Bill

4 REPLIES 4

aborzenkov
3,075 Views

Is FlexClone an option?

billshaffer
3,075 Views

How do you mean?  If I clone the target volume (assuming I can clone a snapmirror target), I'd have to change all the shares, exports, and mounttabs to match the clone name, which is unrealistic.  I guess we could snapmirror to a "holding" vol, then clone it to the same name as the source...

resqme914
3,075 Views

I've ran into this.  Our snapshots are important to us so we ended up turning off the snapshot autodelete.  We use volume autogrow instead.  It's a bit of a pain when a snapmirror source volume autogrows because you'd have to manually resize the destination, but at the same time, we usually catch volumes that autogrow this way... (snapmirror error messages start spewing out on the console).

Another suggestion, with the caveat that I have not tried this, is to use the "prefix" as an "almost-like-an-exclude-list" option.  You would change the defer_delete to prefix and set the prefix to be the first 15 characters (I think) of the destination filer name (you know, the usual snapmirror snapshot name format).  This should make your snapmirror snapshots be the last to be deleted.

You might also want to set your target free space a little bit lower.

billshaffer
3,075 Views

Yeah, I thought about trying to use prefix, but that doesn't guarantee the snapmirror snaps won't get taken, just that they'll get taken last.

Same with the target free space.  Sadly we run our volumes pretty high anyways.

Thanks for the suggestions though!

Bill

Public