Orphaned Disk Snapshot
Does ZopNight manage Orphaned Disk Snapshot?
An orphaned Azure snapshot is 1 whose source disk has been deleted, so it can never anchor an incremental restore chain. ZopNight cross-references every snapshot against live disk IDs, aggregates orphans per subscription and region with count and size, then surfaces deletion recommendations with estimated monthly savings.
Rules that fire on Orphaned Disk Snapshot
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only; savings come from deletion via recommendation remediation. |
An orphaned snapshot is one whose source disk no longer exists, meaning it can never be used for an incremental restore chain and usually serves no purpose. Each one is pure storage waste until deleted.
Same storage meter, zero remaining purpose
An orphan bills exactly like any other snapshot, per GB and indefinitely, but its reason for existing is gone. With the source disk deleted, the snapshot cannot extend an incremental chain, cannot be diffed against a live disk, and in most environments will never be restored. The distinction from an ordinary snapshot matters for triage: a snapshot of a live disk might be a deliberate backup, whereas one pointing at a deleted disk is almost always debris from a decommissioning that stopped one step short.
Detection by set difference, not by tag
ZopNight finds orphans by construction rather than convention. The snapshot enricher first builds a set of every managed-disk resource ID in the subscription, then checks each discovered snapshot’s source-disk reference against that set. Snapshots with a match are parented to their disk as normal azure-snapshot rows; the misses are aggregated into a single azure-snapshot-orphan resource per subscription and region, carrying the orphan count and combined size. The aggregate surfaces as an explicit orphan-cleanup recommendation with estimated monthly savings, eligible for remediation. Deletion is the only lever, since there is nothing here to stop, resize, or retier.
Why decommissioning leaves these behind
Deleting a VM in Azure prompts about its disks, but nothing ever prompts about the snapshots of those disks. Teardown scripts show the same blind spot: they enumerate and remove compute and disks, then exit. The result is a class of storage that outlives every resource that justified it.
Verifying an orphan before deleting it
Azure portal → Snapshots shows each snapshot’s Source disk column; a source that no longer resolves to an existing disk confirms the orphan. Since the parent is already gone, deletion carries none of the restore-chain risk that makes ordinary snapshot cleanup nervous work.