Not weird at all - this is a normal part of the learning curve.
When a vSphere environments starts to use automatic backups the admins usually assume that this reduces the daily work and increases the reliabilty of the complete setup.
Big mistake: once you start to use automatic backups your daily routine has to be adjusted. You MUST monitor the backup tool daily and fix problems asap.
If you neglect that check you will sooner or later run into a scenario like this: snapshots pile up, fill the datastore until the situation ends ugly and requires some serious work ....
If you are lucky you can get away with discarding the very last snapshot and then consolidate the other 86 snapshots in one or two steps with vmkfstools.
Dont hope for an easy solution to release the lock.
The required documentation is not available and the workarounds that I can offer are risky.
So first step is to provide a list of all vmdk-files including date and size and full names.
You need to do that via WinSCP or putty - no chance to do that with the WebUI only.
Then run vmkfstools -D against all vmdks to find out if the complete chain is locked or if only the last snapshots are affected.
For troubleshooting the following files are required:
vmx
vmsd
all vmware.logs
all vmdk-files that do NOT have delta, sesparse. ctk or flat in the name.
If you want help with releasing the locks ... I am on strike at the moment to protest against the missing documentation so at the moment only support via skype is available.
Ulli