Compute Engine VMs whose disks have no snapshot schedule attached

Why a VM without a schedule depends on memory

A snapshot schedule is a resource policy that tells Compute Engine to snapshot a disk on an hourly, daily or weekly cadence and to prune old snapshots after a retention period. Google’s scheduled snapshot guide calls it the best practice for backing up Compute Engine workloads. Without one, the only restore points a VM has are the snapshots someone remembered to take, and those tend to stop the week the person who took them moves team.

Schedules are cheap to get wrong in the other direction too. The schedule reference warns that a schedule created without a retention policy keeps every automatic snapshot indefinitely, and you pay storage on all of them until you delete them by hand.

Spotting VMs whose disks carry no schedule

A disk with no resource policies attached has no snapshot schedule. This lists those disks along with the VM that uses each one:

gcloud compute disks list \
  --filter="-resourcePolicies:*" \
  --format="table(name,zone,users)"

The users column names the instance, so one VM can appear several times, once per unprotected boot or data disk. A VM that appears there needs a schedule on each listed disk, not only on its boot disk.

The one signal behind the finding

ZopNight records, for each Compute Engine instance it inventories, whether a snapshot schedule covers it. The rule fires only when that record says false. There is no age, size or utilisation gate: a new VM and a five-year-old VM are treated the same.

When the rule stays quiet

An instance whose schedule status was never recorded is skipped, so a partial scan cannot produce a finding. A disk-level view of the same gap, including disks with no snapshot at all, is covered by GCP Persistent Disk Without Snapshot. Disks encrypted with a customer-supplied key are a special case: Google does not allow snapshot schedules on them, so they need a different backup method.

What protection costs instead of saves

This is a compliance finding with a $0 saving. Adding a schedule adds snapshot storage to the bill, which is why the retention setting matters as much as the schedule itself.

Adding a schedule to the VM’s disks

1. Create a schedule in the disk’s region, setting retention at creation time because it cannot be added later:

   gcloud compute resource-policies create snapshot-schedule daily-14d \
     --region=REGION --start-time=03:00 --daily-schedule --max-retention-days=14

2. Attach it to each disk the VM uses: gcloud compute disks add-resource-policies DISK_NAME --resource-policies=daily-14d --zone=ZONE.
3. Repeat for data disks, not only the boot disk.
4. After the first run, restore one snapshot to a scratch disk to prove the backup is usable.