Aggressive snap autodelete

[rmharwood]

I was just wondering if anyone else had seen this and can possibly offer an explanation.

I have a 4TB Snapvault secondary volume that had approximately 5 months of backup data inside, maybe about 15 snapshots total. I had snap autodelete enabled on this volume, with the default values I think, and the target free space set at 10%. It was my understanding that once the volume reached 98% capacity ONTAP would start removing the oldest snapshots until the free space was back above 10%.

Unfortunately, last night, autodelete got carried away and removed all but the most recent snapshot. Free space is now at 55%. I've since switched off autodelete and I will have to go back to manually deleting snapshots to free up space. Snap reserve is set at 0%. ASIS is enabled. I'm quite sure that it wasn't necessary to delete all of the snapshots just to get above 10% free.

I'm not sure if I'm hitting an obscure bug or a feature!

ONTAP 7.3.2 on a FAS3140.

Cheers,

Richard

[amiller_1]

Hmm...mind posting the full snap autodelete settings for the volume in question?

[rmharwood]

The following are the autodelete settings right now. I assume that the settings are retained even though I disabled it.

state               : off
commitment          : try
trigger              : volume
target_free_space    : 10%
delete_order            : oldest_first
defer_delete            : user_created
prefix                : (not specified)
destroy_list            : none

[andydustman]

I think I know what the answer is now, having run into this problem myself.

You have a snap reserve of 0%, which is normal procedure for a snapvault secondary. And, you have trigger volume. I think there is a fine distinction between trigger volume and trigger space_reserve. Both seem to be triggered on the same conditions (98%+ space reservation and 98%+ snap reservation), but I suspect that if you have trigger volume, it deletes snaps until both the space reservation and snap reservation are below target_free_space. But if snap reserve is 0%, it can never get there, so it deletes as much as it can.

I'm trying two things to get around this. I think the real solution is to use trigger space_reserve instead trigger volume, but I also set some snap reserve on the volume in question.

[rmharwood]

It's been a while and I haven't used snap autodelete since this. I wasn't pleased that 5 months of snapvault backups got removed. I could have tested how and why it was doing what it was doing but I never got around to it. At the time I was stuck not being able to grow the volume above 4TB because there 4TB was the volume size limit when using ASIS on a 3140. We now run snapvault on a 3160 with ONTAP 8.0.2.

I'm not sure what "space reservation" means in this context. The volume was not thin-provisioned so maybe that's what it means. Typically I associate space reservation in a volume with a non-thin provisioned LUN. At least that's how Operations Manager displays volume statistics. The manual and the "man" page could be a lot clearer if this is the case.

I would be interested to hear your findings.

Thanks,

Richard