CephXXXVII · RBD SnapshotsRBD Snapshots
Taking snapshots that are actually usable
What you'll learn
- Create and name snapshots consistently
- Quiesce a guest filesystem before snapshotting
- Automate snapshot creation with retention
- Distinguish crash-consistent from application-consistent
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
Taking a snapshot is one command. Taking a snapshot you can actually restore from, without a filesystem check and without losing the last transactions, requires the guest to participate. The difference only becomes apparent when you try to use one.
The command
rbd snap create rbd-vms/vm-disk-01@daily-2026-08-18
rbd snap ls rbd-vms/vm-disk-01
Instant, and the image keeps serving I/O throughout.
Three levels of consistency
Crash-consistent — the snapshot looks like the state after a power cut. A journalling filesystem recovers; an application may have lost in-flight work.
Filesystem-consistent — the guest filesystem was frozen, so the snapshot has no in-flight metadata. Mounts cleanly with no recovery.
Application-consistent — the application also flushed and quiesced, so its own state is coherent. This is what a database needs.
Achieving each
# filesystem-consistent, from inside the guest
fsfreeze -f /data
# ... snapshot taken now ...
fsfreeze -u /data
With QEMU guest agent, the hypervisor can do this without logging in:
DOMAIN=vm-db-01
virsh domfsfreeze ${DOMAIN}
rbd snap create rbd-vms/vm-disk-01@consistent-2026-08-18
virsh domfsthaw ${DOMAIN}
For application consistency the application must cooperate:
# PostgreSQL
psql -c "SELECT pg_backup_start('snapshot');"
# ... freeze, snapshot, thaw ...
psql -c "SELECT pg_backup_stop();"
Keep the freeze window short. A frozen filesystem blocks all writes, and the snapshot itself takes milliseconds — so the window should be under a second if the tooling is right.
Naming and automation
# a name that sorts and parses
rbd snap create "rbd-vms/vm-disk-01@auto-$(date -u +%Y%m%dT%H%M%SZ)"
# retention: remove snapshots older than the policy
rbd snap ls --format json rbd-vms/vm-disk-01 \
| jq -r '.[].name' \
| grep '^auto-' \
| sort | head -n -14 \
| xargs -r -I{} rbd snap rm rbd-vms/vm-disk-01@{}
Automation that creates without deleting is how pools fill up. The two belong in the same script.
Quiz
Knowledge check · 4 questions
Q1. What does `fsfreeze -f` before an RBD snapshot achieve?
Q2. No amount of filesystem freezing makes a snapshot application-consistent for a database.
Q3. Improve a snapshot regime for database volumes.
Nightly snapshots of 30 PostgreSQL volumes are taken with a simple `rbd snap create` loop. A recent restore test required a lengthy recovery and lost the last few minutes of transactions.
Q4. Why can different objects in an RBD image reflect slightly different moments during a snapshot?
Passing score: 75%. Answers are checked in this browser.
Production discipline
Wire the freeze and application-quiesce steps into snapshot automation from the start, and keep creation and retention in the same script so a snapshot is never created by something that will not delete it. Restore from a snapshot into a test image on a schedule — the regime is unverified until you have.
Cross-course references
- Kubernetes: VolumeSnapshot with a pre-snapshot hook implements the same coordination
- Linux: LVM snapshots need the identical fsfreeze discipline for a clean mount