← All posts
GCP19 May 2026 · 2 min read

Orphaned Snapshots and Stale Images: Your Storage Bill's Dirty Secret

Backups are good. Backups of disks that no longer exist, kept forever, with no lifecycle policy, are just a storage bill you forgot to read. Here's how to tell them apart.

By The FeckBills team

Orphaned Snapshots and Stale Images: Your Storage Bill's Dirty Secret

Snapshots are the responsible thing to do, right up until they become the thing nobody manages. Every cloud account over a year old has a graveyard of them: incremental snapshots of disks that were deleted long ago, custom images from a base OS three versions back, manual "just in case" backups from a migration everyone's forgotten.

They're cheap per-GB. They're not cheap per-thousand, kept forever.

Two different problems

Truly orphaned snapshots, where the source disk is gone. These are the high-confidence cleanup: the thing they were protecting no longer exists, so unless you specifically need point-in-time recovery of a deleted resource, they're pure cost. This is the easy win.

Stale-but-valid snapshots, where the disk still exists but you've got ninety daily snapshots going back three months because there's no retention policy. This is a lifecycle problem, not a delete-it problem. The fix isn't a one-time cleanup; it's a policy.

Tell them apart before you act. Deleting a legitimate recent backup to save a few pence is how cost optimisation gets a bad name internally.

Finding the candidates

  • Source-disk-gone snapshots: list snapshots and check whether their source disk still exists. Gone = high-confidence reclaim.
  • Age-based staleness: snapshots older than your actual recovery window (90 days is a common line) with no clear retention reason: low confidence, flag for review, don't auto-delete.
  • Custom images nobody's launched from in months, same logic. An image referenced by a live instance template is not a candidate, so check references first.

Fix the cause, not just the symptom

A one-time snapshot sweep feels great and then the graveyard refills in six months. The durable fix:

  1. Set a snapshot schedule with retention: keep N daily, M weekly, and let the rest auto-expire. The cloud will do the deleting for you.
  2. Tag manual snapshots with an owner and an expiry. Untagged manual snapshots are the ones that live forever.
  3. Apply Storage lifecycle rules to move cold backups to cheaper classes (Nearline/Coldline/Archive) before deleting. Sometimes the answer is "tier it," not "bin it."

The one that grows while you're not looking

Storage waste is the one that compounds. Compute waste is roughly flat; snapshot and image sprawl grows, with every day adding another increment. That's why a policy beats a cleanup: you want the line to stop climbing, not just dip once.

How FeckBills helps

FeckBills' gcp.orphaned-snapshots detector splits exactly this way: source-disk-gone snapshots are flagged high-confidence, while merely-old ones get a lower confidence and a "verify this isn't a deliberate backup" note. Legit recent backups aren't flagged at all. You get the safe reclaims surfaced first, ranked by £/mo.

Scan for orphaned snapshots and stop paying to protect things that don't exist.

#gcp#snapshots#images#storage#lifecycle

See your number in 60 seconds

Read-only. Runs in your infra. You decide on every fix.

Run a free scan →