RBD snapshots and copy-on-write

Intermediate⏱ ~17 minrbd

What you'll learn

Explain the copy-on-write snapshot mechanism
Predict the capacity and performance cost of a snapshot
Create, list, and roll back snapshots
Manage snapshot lifecycle to avoid capacity surprises

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 cheap to take and not free to keep, and the cost arrives later as capacity consumption proportional to how much has changed since. A forgotten snapshot on a busy image is one of the more common causes of unexpected pool growth.

The mechanism

Taking a snapshot writes a marker. Nothing is copied:

rbd snap create rbd-vms/vm-disk-01@before-upgrade
rbd snap ls rbd-vms/vm-disk-01
# SNAPID  NAME             SIZE     PROTECTED  TIMESTAMP
#     12  before-upgrade  100 GiB             2026-08-18T09:14:22

The cost arrives on the next write:

1. Guest writes 4 KiB to an object covered by the snapshot
2. The OSD preserves the object's pre-snapshot contents
3. The new data is written
4. Reading the snapshot returns the preserved version;
   reading the image returns the new one

So capacity grows in proportion to how much of the image is modified after the snapshot, not to the image’s size.

The cost profile

	Cost
Taking the snapshot	negligible
Idle image with a snapshot	none
First write to each object after the snapshot	one object copy
Steady state after the copies	normal
Deleting a snapshot	background work to release objects

A snapshot of a mostly-idle image costs almost nothing indefinitely. A snapshot of a database volume rewriting its whole working set daily accumulates capacity fast.

Working with them

rbd snap create   rbd-vms/vm-disk-01@daily-2026-08-18
rbd snap ls       rbd-vms/vm-disk-01
rbd snap rollback rbd-vms/vm-disk-01@before-upgrade    # image must be unmapped
rbd snap rm       rbd-vms/vm-disk-01@daily-2026-08-11
rbd snap purge    rbd-vms/vm-disk-01                   # all of them

# protect a snapshot that clones depend on
rbd snap protect rbd-vms/golden-image@v1

Rollback rewrites the image to the snapshot’s contents and requires the image to be unmapped — it is not instantaneous and it discards everything written since.

Capacity accounting

rbd du rbd-vms/vm-disk-01
# NAME                        PROVISIONED  USED
# vm-disk-01@daily-2026-08-17     100 GiB   4.2 GiB
# vm-disk-01@daily-2026-08-18     100 GiB   3.8 GiB
# vm-disk-01                      100 GiB    22 GiB
# <TOTAL>                         100 GiB    30 GiB

The per-snapshot USED column is what each snapshot is holding that the live image no longer references — the actual cost of retaining it.

Quiz

Knowledge check · 4 questions

Q1. What does taking an RBD snapshot of a 500 GB image immediately consume?

500 GB, because taking a snapshot copies the whole image into the snapshot An amount proportional to the number of objects the image has allocated Half the image size, since only the allocated objects are duplicated Essentially nothing — the cost arrives as objects are modified afterwards
Q2. An RBD snapshot is automatically crash-consistent across the whole image.

True False
Q3. Explain unexpected pool growth.

A pool backing 40 database VMs has grown 18 TB in three weeks with no new volumes provisioned and no reported data growth in the databases. `rbd du` on several images shows large per-snapshot USED values.
Q4. Why are RBD snapshots consistent per object but not necessarily across the image?

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

Production discipline

Create snapshots only from automation that also deletes them, and audit for snapshots older than the retention policy as a routine check — manual snapshots taken during incidents are the ones that persist. Use the per-snapshot USED figure when explaining capacity growth; it attributes the consumption precisely.

Cross-course references

Kubernetes: VolumeSnapshot lifecycle needs the same automated retention
Linux: LVM and ZFS snapshots have the identical copy-on-write growth profile