Compute Engine persistent disks with no snapshot and no snapshot schedule

What a disk without snapshots cannot get back

A persistent disk replicates for durability, which protects against hardware failure, not against you. A rm -rf in the wrong directory, a failed schema migration or deleting the disk itself are all faithfully applied. A snapshot is the point-in-time copy you restore from.

Snapshots are cheaper than many teams expect. Google’s snapshot overview explains that standard snapshots are incremental by default: each one stores only data changed since the previous one, so a daily schedule on a quiet disk adds little storage.

Finding disks that nothing protects

List disks with any attached resource policies, which include snapshot schedules:

gcloud compute disks list --format="table(name, zone, sizeGb, resourcePolicies.list())"

Then list which disks already have snapshots:

gcloud compute snapshots list --format="value(sourceDisk)" | sort -u

A disk with an empty policy column and no entry in the second list is unprotected.

How ZopNight decides a disk has no snapshot

ZopNight checks each persistent disk against the project’s snapshots when it inventories Compute Engine, and records whether the disk has one. A snapshot schedule attached to the disk counts as protection, even before its first snapshot runs. The rule fires only when that record says no snapshot exists. There is no age or size threshold.

Disks it deliberately skips

Disks that Kubernetes manages are excluded: names starting pvc-, gke- or kubernetes-dynamic-pvc-, and disks carrying the GKE CSI driver’s goog-gke-volume label. Those volumes follow the cluster’s own backup and lifecycle. If the snapshot listing fails during a scan, ZopNight leaves the record empty rather than writing “no snapshot”, so an API error cannot produce a false finding. Old snapshots are a cost issue covered by GCP Old Disk Snapshot.

A recovery gap with no saving

ZopNight reports $0 saving. Adding a schedule adds snapshot storage cost. What it buys is the ability to restore after a mistake instead of rebuilding from scratch.

Putting the disk on a schedule

1. Take a manual snapshot now: gcloud compute snapshots create SNAPSHOT_NAME --source-disk=DISK_NAME --source-disk-zone=ZONE.

2. Create a schedule in the disk’s region, following Google’s scheduled snapshot steps:

   gcloud compute resource-policies create snapshot-schedule daily-7d \
     --region=REGION --start-time=22:00 --daily-schedule \
     --max-retention-days=7 --on-source-disk-delete=keep-auto-snapshots

3. Attach it: gcloud compute disks add-resource-policies DISK_NAME --resource-policies=daily-7d --zone=ZONE.

4. Test a restore to a new disk once, so you know the process works.