We are using a SnapLock policy on our snapshots, so that they are locked from deletion, this works just fine...
We had to do a restore the other day, and created a flexclone from a snapshot... but when we were wanted to delete this flexclone the system tells us that we cannot delete it becuase the underlying snapshots is snaplocked... we do of cause not want to delete the snapshot, just want to delete the flexclone... this has to be a bug, or have I missed something? (we are talking ONTAP 9.14.1P5)
#Snapshot snapshots, locks flexclone volumes from being deleted?
mellow terrace
quiet tinsel
This is a know issue but I don't think it is classified as a bug. The cloned volume inherits the Snapshot Policy of the original volume and so all snapshots created in the clone will also be locked. There is an RFE filed against ONTAP for that behavior to change apparently though
see here (the KB is talking about Veeam but the issue is not Veeam specific)
your only option at this point is to manually set the snapshot schedule to "none" quickly after creating the flexclone (and don't create clones at times where there could be a race against snapshot creation, like around 0:00-0:05 or so)
mellow terrace
Well there isn't even any snapshts on the cloned volume, but still it's locked... this is not from Veeam, it's actually from SnapCenter for vSphere... classic NetApp.. let's put a lot of new cool features into ONTAP, but wait a few years before we fully support it in our own software 😉
quiet tinsel
as I said, the KB is not Veeam specific
mellow terrace
as I said, the KB is not Veeam specific
Well there is actually support for SnapLock in the SnapCenter for vSphere policies... One would expect that NetApp would test their software just a little better... I can only see this to be a small and easy "fix" to disable or remove the snapshot policy on a cloned volume... I struggle to think of a setup where it would make sense to "reuse" the same snapshot policy on a flexclone... And if it's just me, they could at least add this as an option when you create your clones...
hardy panther
It's that way on purpose. There is a flag on the volume clone create called "snaplock-type" which gets passed.
It is created from a locked snapshot so split the clone first then you can delete it.
hardy panther
https://docs.netapp.com/us-en/ontap/volumes/create-flexclone-task.html#create-a-flexclone-of-any-snaplock-type
Borrowing from someone else:
See "Create a FlexClone of any SnapLock type"
"By default, a FlexClone volume is created with the same SnapLock type as the parent volume. However, you can override the default by using the snaplock-type option during FlexClone volume creation."
"parent volume" is interchangeable with snapshot
quiet tinsel
that flag doesn't help with tamperproof snapshots though