Orphaned Snapshot
Does ZopNight manage Orphaned Snapshot?
An orphaned snapshot is one whose source Persistent Disk has been deleted, so it can never serve an in-place restore. ZopNight detects orphans during discovery by matching every snapshot against the live disk list, aggregates them into one resource with total count and GB, and surfaces immediate deletion candidates.
Rules that fire on Orphaned Snapshot
No active rule family targets Orphaned Snapshot today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
An orphaned snapshot is a snapshot whose source disk no longer exists, meaning it can never be used for an in-place restore workflow and often belongs to a deleted environment. Orphans are the purest form of storage waste.
Backups that outlive their disks
The meter itself is ordinary snapshot storage (per GB of stored snapshot data per month), but the meaning changes when the source disk is gone. A parented snapshot is insurance on a live disk; an orphan is storage paying for a machine that was torn down. Deleting a VM or an environment removes its disks, yet GCP deletes nothing downstream: every snapshot those disks ever produced keeps billing, and any snapshot schedule that referenced them simply stops adding new entries while the existing chain persists untouched.
How the orphan set is built
During discovery, ZopDev lists every disk in the project through Cloud Asset Inventory and checks each snapshot’s source disk against that live-disk lookup. Snapshots whose disk still exists are parented to it; the rest are the orphans, and they are aggregated into a single orphaned-snapshot resource carrying the total unit count and combined size in GB. That aggregation is deliberate: a project can hold hundreds of orphans, and one roll-up row with totals reads better than hundreds of near-identical lines. Recommendations then present the set as immediate deletion candidates.
Why environments leave orphans behind
Orphans concentrate where environments churn. Torn-down test and staging projects whose disks had daily snapshot schedules are the biggest source. Recreated VMs are the second: replace a disk during an incident and its old snapshot chain is instantly orphaned. Third are one-off backups taken before deleting something, which achieve their purpose the moment the deletion succeeds and then never get cleaned up.
Verifying an orphan before deleting it
Google Cloud console → Compute Engine → Snapshots shows the Source disk column; entries pointing at deleted disks are the orphan set. One caution before bulk deletion: an orphan can still create a brand-new disk, so a snapshot deliberately kept as an archive of a decommissioned system is not waste. Confirm archival intent, then delete the rest.