Volume Snapshots
How can a snapshot be ready in seconds, and why is it not always a backup? A VolumeSnapshot binds to a cluster-scoped VolumeSnapshotContent the way a PVC binds a PV, and on a copy-on-write backend the snapshot is a frozen map of the volume blocks, so only a block written later is kept twice and a restore gets a new, crash-consistent volume holding the older state. Here the volume, snapshot and restore share one Ceph RBD pool, and losing it loses all three.
Play the animation 6 steps, animated, best on a wide screen
Volume Snapshots, step by step
-
Pod db-0 writes to PVC data-1, whose volume lives in a Ceph pool. The card draws that volume as six blocks, A to F, and every write gives a block a new version: this one turns C v1 into C v2. The volume keeps changing like this for as long as the Pod runs.
Play from step 1 -
You create VolumeSnapshot snap-1 with source data-1 and a VolumeSnapshotClass that names the CSI driver. The snapshot controller creates a cluster-scoped VolumeSnapshotContent and binds the two one to one, the same pair shape as a PVC and its PV. All three kinds are CRDs installed with that controller, not built in.
Play from step 2 -
At 10:00 the csi-snapshotter sidecar sees the new content and sends CreateSnapshot to the CSI driver, which runs it against the pool. On a copy-on-write backend like this one no data moves: the snapshot is a frozen map pointing at the six blocks exactly as they are now, C v2 included. That is why it can be ready in seconds.
Play from step 3 -
At 10:05 the Pod writes block C again. The pool keeps the old C v2 for the snapshot before the new version lands, so this one block now exists twice. The live volume reads C v3, while snap-1 still sees every block exactly as it was at 10:00.
Play from step 4 -
To go back, create PVC restore-1 with dataSource snap-1, no smaller than its restoreSize, in a class of the same driver, here the very same class. Provisioning builds a new volume holding C v2, the 10:00 state, not the live C v3. Nothing quiesced db-0 first, so it is only crash consistent: what it held in memory at 10:00 is not in it.
Play from step 5 -
All three sit in one pool. If that pool is lost, the live volume, the snapshot and the restored copy go with it, while snap-1 and its content stay in the API naming data that is gone. On a backend like this a snapshot is not a backup until it is copied somewhere else.
Play from step 6