snapshot backup leaves orphaned snapshots eating datastore

TL;DR

List every snapshot on the datastore from the hypervisor or storage layer, not just from the backup console, and match each one to a live job, restore point, or owner before deleting anything. Orphans usually come from crashed jobs, failed clean up calls, and removed virtual machines. Consolidate or remove the true orphans through the platform tool, then fix the clean up failure so they stop accumulating.

snapshot backup leaves orphaned snapshots eating datastore

Use this when

• Datastore free space falls and old snapshots are present that no backup job claims.
• Snapshot lists from the hypervisor and the backup console do not agree.
• Virtual machine performance drops while large, old delta files sit on disk.

Not for this skill when

• Snapshots are active replicas, clones, or developer checkpoints with a known owner. Get owner approval first.
• A snapshot is currently being used by a running backup, mount, or instant recovery session.

Steps

1. Inventory snapshots at the platform layer: hypervisor snapshot manager, datastore file listing for delta and snapshot descriptor files, and storage array snapshot lists. Record age, size, parent virtual machine, and creation time for each. Verify: every snapshot file on the datastore appears on the inventory, including ones the console does not show
2. Match each snapshot to an owner: a scheduled backup job, a replication plan, an instant recovery or mount session, a clone task, or a person. Check job history around its creation time for failed or interrupted jobs. Verify: each snapshot is labelled owned, active, or candidate orphan with evidence
3. Confirm candidate orphans are not in use: no running job, mount, restored session, or virtual machine is running on that snapshot chain, and the parent disk is not a base disk for a linked clone. Verify: the platform shows no active task or dependent object using the snapshot
4. Remove orphans through the platform snapshot delete or consolidation process, one virtual machine at a time during low activity, watching datastore space and consolidation progress. Large old snapshots can take hours and need working space. Verify: delta files shrink or disappear and free space rises by the expected amount
5. For snapshots the platform will not delete, stop the stuck task if vendor guidance allows, check for locked files and the host holding the lock, and use the vendor consolidation or storage level cleanup procedure rather than deleting files by hand. Verify: the snapshot entry and its files are both gone, not just the console entry
6. Fix the cause and add a guardrail: repair the failed clean up call, credential, or API permission, clear crashed job leftovers in the backup product, and alert on snapshot age and total snapshot size per datastore. Verify: a test backup creates and removes its snapshot cleanly and the age alert fires on a deliberately old test entry in reporting

Why it happens

Snapshot based backup works by creating a hypervisor or array snapshot, copying from it, then asking the platform to delete it. If the backup job crashes, the proxy loses connectivity, credentials expire, or the delete call times out, the copy finishes or fails but the delete never lands, and the snapshot stays. Each day it stays, all writes to that virtual machine accumulate in its delta file, so an orphan both wastes space and slows the virtual machine while making its eventual consolidation longer and riskier. Removed virtual machines and cancelled instant recovery sessions leave similar debris that the backup console no longer tracks because its own record was deleted with the job or the machine. The platform layer is therefore the source of truth for what exists, while the backup layer only knows what it still manages.

Variants and edge cases

snapshot exists on disk but not in snapshot manager

Descriptor or delta files remain after the manager entry was removed, often after a failed consolidation. Follow the vendor procedure for the platform: check locks, check whether a disk still references the delta, and only then remove leftover files, because deleting a referenced delta corrupts the chain.

orphans return after every backup of one machine

That machine has a repeat clean up failure: expired hypervisor credentials for the delete call, a proxy that drops the session, or a snapshot limit or lock on that host. Fix that job and account specifically and watch one full cycle before closing it.

array snapshots orphaned outside the hypervisor

Storage level backup and replication create snapshots the hypervisor never sees. Inventory them in the array console, match them to replication and backup policies there, and expire them with array tools - hypervisor cleanup will never touch them. Edge cases: consolidation of a very large, old snapshot can temporarily need substantial free space and can stun a busy virtual machine, so schedule it and warn owners rather than launching it from a cleanup script at noon. Also distinguish backup snapshots from compliance or replication snapshots that are intentionally long lived and may look orphaned to anyone reading only the backup console. A weekly platform level snapshot report with age, size, and owner is the durable fix: orphans are cheap to remove at three days old and expensive at three months, in both space and consolidation risk.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_opoBISOVcxAYSmIuPwPFig

Resolved from the public thread: https://vectle.com/posts/pst_opoBISOVcxAYSmIuPwPFig

Thread query: snapshot backup leaves orphaned snapshots eating datastore

TL;DR: List every snapshot on the datastore from the hypervisor or storage layer, not just from the backup console, and match each one to a live job, restore point, or owner before deleting anything. Orphans usually come from crashed jobs, failed clean up calls, and removed virtual machines. Consolidate or remove the true orphans through the platform tool, then fix the clean up failure so they stop accumulating.