Snapshots as a control: what they cover and what they cost

Intermediate⏱ ~18 minrbdceph

What you'll learn

Identify what snapshots protect against
Understand snapshot capacity behaviour
Manage snapshot retention
Recognise the limits

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 the cheapest data protection available and their capacity behaviour surprises people who treat them as free.

What snapshots cover

Threat	Same-cluster snapshot
Accidental deletion of a file inside an image	yes
Accidental deletion of the image	yes, if the snapshot survives
Application corruption, detected quickly	yes
A bad application deployment	yes
Cluster loss	no
An actor who can delete snapshots	no
Ransomware with cluster credentials	no

POOL=rbd-vms
IMAGE=vm-disk-01
rbd snap create ${POOL}/${IMAGE}@pre-deploy
rbd snap ls ${POOL}/${IMAGE}

# Substitute your own values before running:
POOL=rbd-vms
IMAGE=vm-disk-01

# and the fast recovery path they enable
rbd snap rollback "$POOL/$IMAGE@pre-deploy"

A pre-change snapshot before any risky operation is the highest-value
minute in most maintenance procedures.

Capacity behaviour

A snapshot costs nothing at creation. It costs as the live image
diverges from it: every overwritten object must retain its snapshotted
version.

POOL=rbd-vms
IMAGE=vm-disk-01
rbd du ${POOL}/${IMAGE}

NAME             PROVISIONED  USED
image01@snap1        500 GiB   80 GiB
image01@snap2        500 GiB   14 GiB
image01              500 GiB  180 GiB
<TOTAL>              500 GiB  274 GiB

Workload	Snapshot growth
Read-heavy	negligible
Append-only	small
Random overwrite	approaches the overwrite volume
A full-image rewrite	approaches the image size

# what snapshots are costing across a pool
POOL=rbd-vms
rbd ls ${POOL} | while read img; do
  rbd du "${POOL}/$img" --format json 2>/dev/null | python3 -c '
import sys,json
d = json.load(sys.stdin)
tot = sum(i.get("used_size",0) for i in d.get("images", []))
snaps = sum(i.get("used_size",0) for i in d.get("images", []) if i.get("snapshot"))
if tot: print("%-24s total %7.1f GiB  snapshots %7.1f GiB" %
              (d["images"][0]["name"], tot/1024**3, snaps/1024**3))'
done

Retention

# snapshot schedules, managed by the rbd_support module
rbd mirror snapshot schedule ls 2>/dev/null
ceph mgr module ls --format json | python3 -c '
import sys,json; print("rbd_support" in json.load(sys.stdin)["enabled_modules"])'

# Substitute your own values before running:
POOL=rbd-vms
IMAGE=vm-disk-01

# manual retention: keep the last 14
rbd snap ls "$POOL/$IMAGE" --format json | python3 -c '
import sys,json
snaps = sorted(json.load(sys.stdin), key=lambda s: s["id"])
for s in snaps[:-14]: print(s["name"])' | \
while read s; do rbd snap rm "$POOL/$IMAGE@$s"; done

Removing a snapshot returns capacity but generates work: the objects it
was holding must be trimmed, which is I/O the cluster does in the
background.

ceph -s | grep -i snaptrim

The limits

A snapshot is a control against the threats that reach the data.
It is not a control against the threats that reach the cluster.

Limit	Consequence
On the same cluster	shares the cluster’s fate
Deletable by the same credential	an actor with access removes both
Capacity cost scales with change	unbounded retention is not free
Trim load on removal	bulk removal generates background I/O
Rollback loses post-snapshot data	it is a revert, not a merge

Quiz

Knowledge check · 4 questions

Q1. What does removing many snapshots at once generate?

A monitor election, because removing snapshots rewrites the snapshot context carried in the OSDMap Snaptrim work — every object whose last reference disappeared must be deleted, which can compete with client I/O for hours A rebalance, because the freed space changes each OSD's utilisation and the balancer reacts to that difference A deep scrub of every affected PG, since the object set has changed and its checksums have to be reconfirmed
Q2. A snapshot of a read-heavy image can be retained for months at almost no capacity cost.

True False
Q3. Design a snapshot retention policy.

RBD images serving VMs are snapshotted hourly with no retention limit. Pool usage is growing faster than the VMs' data.
Q4. What does `rbd snap rollback` do to data written after the snapshot?

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

Production discipline

Take a snapshot before any risky change — it costs seconds and converts an unrecoverable operation into a revertible one. Stage bulk snapshot removal rather than scripting one cleanup; releasing a month of snapshots on a heavily-overwritten image can generate hours of trim load.

Cross-course references

Kubernetes: a pre-upgrade volume snapshot serves the same rollback role
Linux: copy-on-write snapshot cost tracks change rate, not data size