CSI snapshots and what they are not

Advanced⏱ ~18 minkubectlrbd

What you'll learn

Create and restore CSI snapshots
Understand the underlying RBD operations
Explain why snapshots are not backups
Design a backup strategy that uses them correctly

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

Snapshots are fast, cheap, and frequently mistaken for backups. The distinction is not pedantic — it determines what survives which failures.

Creating a snapshot

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: ceph-rbd-snapclass
driver: rbd.csi.ceph.com
parameters:
  clusterID: <fsid>
  csi.storage.k8s.io/snapshotter-secret-name: csi-rbd-secret
  csi.storage.k8s.io/snapshotter-secret-namespace: ceph-csi
deletionPolicy: Delete

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: data-snap-1
spec:
  volumeSnapshotClassName: ceph-rbd-snapclass
  source:
    persistentVolumeClaimName: data

IMAGE=vm-disk-01
kubectl get volumesnapshot data-snap-1
rbd -p k8s-rbd snap ls ${IMAGE}

Restoring

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-restored
spec:
  storageClassName: ceph-rbd
  dataSource:
    name: data-snap-1
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes: [ReadWriteOnce]
  resources: { requests: { storage: 10Gi } }

The restore creates a new volume from the snapshot — a clone — rather than reverting the original.

NEW_IMAGE=vm-disk-01
rbd -p k8s-rbd ls
rbd info k8s-rbd/${NEW_IMAGE} | grep parent

Why a snapshot is not a backup

Failure	Snapshot survives?
Accidental file deletion in the volume	yes
Accidental PVC deletion	depends on deletion policy
Application corruption	yes, if taken before
Ceph pool deleted	no
Ceph cluster lost	no
Datacentre lost	no
Ransomware with cluster access	no
Snapshot deleted maliciously or accidentally	no

A snapshot lives in the same pool, in the same cluster, in the same datacentre as the data it protects. It survives failures within the volume and none of the failures that affect the cluster.

Consistency

A snapshot captures the RBD image at a point in time.
It does not quiesce the application or flush the guest filesystem.
The result is crash-consistent, not application-consistent.

Consistency level	Achieved by
Crash-consistent	a plain snapshot
Filesystem-consistent	freeze the filesystem before snapshotting
Application-consistent	quiesce the application, then snapshot

# a pre-snapshot hook, application-specific
lifecycle:
  preStop:
    exec:
      command: ["/bin/sh","-c","fsfreeze -f /data"]

Most databases can recover from a crash-consistent snapshot, and most would prefer not to have to.

A strategy that uses them correctly

Snapshots:  frequent, short-retention, fast recovery from local mistakes
Backups:    less frequent, off-cluster, protection from cluster-level loss

# a backup: export the data out of the cluster
# the CSI-provisioned image name, from `rbd ls k8s-rbd`:
IMAGE=csi-vol-8f3a1c72-5b0d-4e9a-9d21-6c4f0b7e3a15

rbd export-diff --from-snap prev "k8s-rbd/$IMAGE@now" - | \
  restic backup --stdin --stdin-filename "$IMAGE.diff"

Quiz

Knowledge check · 4 questions

Q1. Why does restoring from a CSI snapshot create a new volume rather than reverting the original?

RBD does not support reverting an image to a snapshot, so the CSI driver has no operation to call Kubernetes forbids in-place changes to a bound PV, so any restore has to produce a new object Cloning is faster, since a revert would have to roll back every object the image has written since the snapshot was taken Reverting discards every write since the snapshot and cannot be done safely while a pod has the original mounted
Q2. A CSI snapshot protects against loss of the Ceph cluster.

True False
Q3. Design data protection for a stateful application.

A team relies on hourly CSI snapshots as their backup strategy for a production database. They have never tested a restore.
Q4. What consistency level does a plain CSI snapshot provide, and what does that mean?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Treat snapshots as fast local recovery and add a separate off-cluster backup — a snapshot lives in the pool it protects and survives none of the cluster-level failures. Test the restore path end to end to a usable application, and repeat the test periodically.

Cross-course references

Kubernetes: VolumeSnapshots are consistently mistaken for backups across storage backends
Linux: LVM snapshots have exactly the same scope and the same misconception