Persistent disks with no snapshot anywhere
What does ZopNight detect here?
Persistent disks with zero snapshots have no point-in-time recovery if data is corrupted or deleted. ZopNight fires only when the discoverer positively recorded has_snapshot=false, skips Kubernetes-managed disks whose backups belong to the control plane, and recommends a snapshot schedule: daily with 7-day retention is the baseline.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-144 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | disk_backup.go |
Where it applies
A disk with no history
Persistent disks replicate within their zone against hardware failure, but replication
is not recovery: corruption, ransomware, and accidental deletion replicate too. A disk
with zero snapshots has exactly one version of its data, the current one, and any
mistake becomes permanent the moment it syncs. The discoverer resolves this per disk and
stamps has_snapshot explicitly in both directions; the rule fires only on a recorded
false, so a disk whose snapshot state was never inspected is silently skipped rather
than presumed unprotected.
Why GKE disks are exempt
Disks created by Kubernetes (PVC backings and GKE node boot disks) are excluded before any other logic. Their backup story belongs to the cluster layer (volume snapshots, Backup for GKE), and a disk-level advisory on them would nag the wrong team about the wrong mechanism. The same Kubernetes-managed gate protects these disks in the unattached- disk delete rule, RC-112; the two rules share one definition of “not yours to touch”.
Schedules beat manual snapshots
A manual snapshot is a good first move and a bad steady state, because it ages. The durable fix is a resource policy: create a snapshot schedule (daily, 7-day retention as the baseline) and attach it to the disk, after which snapshots happen without anyone remembering them. Multi-day retention matters because corruption is often discovered days late; a single rolling snapshot can rotate the damage into your only copy.
List disks lacking snapshots
gcloud compute disks describe my-disk --zone us-central1-a \ --format="value(name,resourcePolicies)"An empty resourcePolicies means no schedule is attached; cross-check existing one-off
snapshots with gcloud compute snapshots list --filter="sourceDisk~my-disk".
Incremental cost is small
GCP snapshots are incremental, and after the first each stores only changed blocks, so the storage cost of protecting a typical disk is a small fraction of the disk itself. This is a $0-savings compliance finding: the recommendation spends a little to remove a data-loss scenario, and no cost-materiality floor applies to it.