# Orphaned or Over-Retained Compute Engine Disk Snapshots Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/orphaned-or-over-retained-compute-engine-disk-snapshots Standard and archive snapshots of Compute Engine disks are not deleted when their source disk is deleted, and they keep billing for stored data until... By: PointFive Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) The short version Standard and archive snapshots of Compute Engine disks are not deleted when their source disk is deleted, and they keep billing for stored data until someone deletes them. PointFive Research Cloud cost research at PointFive GCP service [GCP Compute Engine](https://www.pointfive.co/efficiency-hub/cloud-services/gcp-compute-engine) Category [Storage](https://www.pointfive.co/efficiency-hub/service-category/storage) Reference CER-0466 Type Excessive Data Retention ## Explanation Why the waste happens and who it affects. Snapshot schedules make this worse by default: a schedule's retention policy is optional, schedules without one retain snapshots indefinitely, and the default source-disk deletion rule (KEEP\_AUTO\_SNAPSHOTS) keeps scheduled snapshots permanently after the disk is gone. Manual snapshots taken before upgrades, migrations or incident work are also rarely cleaned up. The result is a snapshot inventory that grows with every disk ever backed up, including disks and VMs deleted long ago, and retention windows far longer than any recovery objective. Because snapshots are incremental, deleting older ones saves less than their nominal size, but whole chains for deleted disks can be removed entirely. Teams also keep long-term compliance copies as standard snapshots when archive snapshots would be cheaper. ## Billing model The pricing dimensions that drive this cost. Rates depend on snapshot type and storage location (regional or multi-regional). Standard snapshot storage Billed per GiB-month of compressed, incremental stored data, prorated per second with a 1-hour minimum Archive snapshot storage Lower storage rate for rarely restored data, billed for a minimum of 90 days, plus a per-GiB retrieval charge when used to create a disk Snapshot chain Deleting a snapshot moves data needed by later snapshots into the next one, so savings are less than the deleted snapshot's apparent size Recycle Bin Deleted standard snapshots are held for 3 days by default; Google states Recycle Bin storage is free during Preview and will be billed at standard rates after GA ## How to detect 4 checks to find it in your estate. - List snapshots with sourceDisk, storageBytes and creationTimestamp (gcloud compute snapshots list) and match sourceDisk against existing disks to find snapshots of deleted disks - Group snapshots by source disk and flag those older than the documented recovery requirement - List snapshot schedules (gcloud compute resource-policies list) and check snapshotSchedulePolicy.retentionPolicy.maxRetentionDays and onSourceDiskDelete; schedules with no retention or KEEP\_AUTO\_SNAPSHOTS keep snapshots indefinitely - Find standard snapshots kept only for compliance for longer than 90 days, which are candidates for archive snapshots ## How to fix 4 ways to remove the waste. - Delete snapshots of deleted disks and manual snapshots that are no longer needed for recovery or compliance - Set maxRetentionDays on every snapshot schedule to match the RPO and retention policy, and set onSourceDiskDelete to APPLY\_RETENTION\_POLICY so scheduled snapshots expire after the disk is deleted; a retention policy is not applied retroactively, so delete the snapshots a schedule created before it had one manually - Use archive snapshots for copies that must be kept for months or years and are rarely restored, accounting for the 90-day minimum and retrieval charges - Use regional snapshot storage where multi-regional redundancy is not required, and label snapshots with owner and purpose at creation ## Documentation Vendor references for pricing and configuration. - [About archive and standard disk snapshots docs.cloud.google.com](https://docs.cloud.google.com/compute/docs/disks/snapshots) - [About snapshot schedules for disks docs.cloud.google.com](https://docs.cloud.google.com/compute/docs/disks/about-snapshot-schedules) - [Disk and image pricing cloud.google.com](https://cloud.google.com/compute/disks-image-pricing) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - GCP Compute Engine CER-0465 ### [Unused Custom Compute Engine Images](https://www.pointfive.co/efficiency-hub/inefficiencies/unused-custom-compute-engine-images) Custom images are billed for storage for as long as they exist, whether or not any VM or disk is ever created from them again. Image build pipelines (Packer, CI jobs, golden-image processes) typically publish a new image version for every... Storage - GCP Compute Engine CER-0461 ### [Unattached Persistent Disk or Hyperdisk Volume](https://www.pointfive.co/efficiency-hub/inefficiencies/unattached-persistent-disk-or-hyperdisk-volume) Persistent Disk and Hyperdisk volumes are billed for their full provisioned size until they are deleted, whether or not any VM is using them. Disks become detached and forgotten in predictable ways: a VM is deleted with auto-delete turned... Storage - GCP Compute Engine CER-0463 ### [Long-Stopped Compute Engine VM Retaining Disks and Static IPs](https://www.pointfive.co/efficiency-hub/inefficiencies/long-stopped-compute-engine-vm-retaining-disks-and-static-ips) Stopping a Compute Engine VM ends vCPU and memory charges, which is why stopping is the usual response to an unneeded machine. But the VM's resources remain: its boot and data disks keep billing for their full provisioned size, a static... Storage --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.