Day 64: Snapshots; why StatefulSets aren't a backup
Snapshots: point-in-time copies
A VolumeSnapshot (via CSI) captures a point-in-time copy of a PV's data, which can later be used to provision a new PVC pre-populated with that data — useful for cloning environments or as one building block of a backup strategy.
Why StatefulSets aren't a backup strategy
A StatefulSet's stable storage means a Pod restart doesn't lose data — but it does nothing to protect against the data itself being corrupted, a bad migration, an accidental deletion, or the underlying storage backend failing. Stable identity is not the same guarantee as a recoverable backup: you still need scheduled, tested snapshots or dumps stored somewhere independent of the running cluster.
This is exactly the distinction Phase 15 will make precise for Postgres specifically (PITR/WAL archiving), and Phase 24 will make precise for disaster recovery in general (RTO/RPO, *tested* backups) — 'my data survives a Pod restart' and 'my data survives a real disaster' are different guarantees entirely.
Key terms
- VolumeSnapshot
- A point-in-time copy of a PV's data, provisionable as a new pre-populated PVC.
Phase 10 complete — you should now be able to
Your database runs as a StatefulSet with a PVC. Someone asks: "do we need backups too, since Kubernetes already preserves the volume?" What's the correct answer?