I didn’t set out to do a VMware snapshots cleanup. I was just getting familiar with a new environment — and that’s exactly how I found snapshots that had quietly outlived whatever reason they were created for.
The Environment
The VMs in question had been in production since 2024, when a factory environment was first completed. In early 2025, a mid-cycle change went out to the related systems, and someone took snapshots beforehand — the usual just-in-case move. The factory environment ran a mix of application and database VMs supporting the plant’s production line, which made the unnoticed snapshot chain more than just a storage inconvenience. Any snapshot left running on a database VM adds I/O overhead every time that VM writes to disk — so this wasn’t a purely cosmetic cleanup issue.
Nobody went back and cleaned them up.
Finding Them
I joined this environment at the end of 2025, and while getting familiar with the setup, I didn’t just take the documentation at face value — I went through the actual VMs one by one. That’s when I found it: snapshots from the early-2025 change were still sitting on roughly ten VMs, months after that change had been completed and verified.
VMware Snapshot Cleanup: What I Actually Did
They weren’t ancient by any stretch, but they’d clearly outlived their purpose. I checked the change history on each one to confirm they were safe to remove, then deleted them by hand — scripting wasn’t really an option here given how the change records were organized.
How This Fed Into a Bigger Outage
This wasn’t just a standalone cleanup task, either. These accumulated snapshots were part of what caused an outage I wrote about separately, when a media volume on our backup server filled up and took the backup VM down with it. Snapshots eat space quietly, and if nobody’s watching that trend, they can end up causing a failure that looks like it came from somewhere else entirely.
What Changed
A few things changed in how I handle snapshots after this:
- Snapshots now get a deletion date attached the moment they’re created, not just a reason. “Taken for the March change” isn’t good enough — it needs to be “taken for the March change, gone by April.”
- I don’t assume an environment I’ve inherited is clean. Walking through what’s actually running, not just what’s documented, is part of getting up to speed on any new infrastructure.
- Snapshot count and age are now something I glance at during regular storage reviews, not just when a disk-full alert goes off.
- Scripting the cleanup wasn’t realistic here, so a periodic manual check is what I’ve got — and that’s still a lot better than no check at all.
The Actual Fix
A snapshot only stays useful as long as everyone remembers it’s temporary. Fancier deletion scripts wouldn’t have caught this one — giving every snapshot a deadline from day one would have.
FAQ
How often should I check for old VMware snapshots?
Somewhere between monthly and “whenever you’re doing a storage review anyway” — the point is a fixed cadence, not waiting for an alert to tell you.
Can old snapshots actually cause a backup failure?
Indirectly, yes. They grow over time and eat into datastore space, and if that trend isn’t tracked, it can quietly contribute to a volume filling up somewhere else — which is exactly what happened here.
How do I find old snapshots in vCenter?
In the vSphere Client, right-click each VM and open Snapshot Manager — it lists every snapshot along with its creation date. For larger environments, PowerCLI’s Get-VM | Get-Snapshot command is faster, since it pulls every snapshot across every VM in one pass instead of clicking through them one by one.
Related reading:
- These leftover snapshots were part of what caused The Day Our Backup Server Went Down.
- The same pattern showed up again later, from a different angle — see NetBackup Kept Failing on One VM. The Datastore Was Almost Full.