Snapshots, clones, and images: what each one is

Intermediate⏱ ~16 minrbd

What you'll learn

Distinguish images, snapshots, and clones precisely
Choose the right one for a given requirement
Predict the capacity behaviour of each
Avoid the errors that come from conflating them

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

“Take a snapshot” and “make a copy” are used interchangeably in conversation and mean completely different things in Ceph. The difference determines whether your backup survives the loss of the pool it protects.

The three things

Image — an independent block device. Its own objects, its own lifecycle, no dependencies.

Snapshot — a read-only point in time within an image. Not separately mountable, not independent, and it disappears if the image is deleted.

Clone — a new writable image whose unwritten regions read from a snapshot. Independent identity, dependent data.

rbd create --size 100G rbd-vms/base            # image
rbd snap create rbd-vms/base@v1                # snapshot inside it
rbd snap protect rbd-vms/base@v1
rbd clone rbd-vms/base@v1 rbd-vms/derived      # clone: new image, parent link
rbd cp rbd-vms/base rbd-vms/independent        # full copy: no link

The comparison

	Image	Snapshot	Clone
Separately addressable	yes	no	yes
Writable	yes	no	yes
Independent of anything	yes	no	no
Survives parent deletion	n/a	no	no
Initial capacity cost	as written	none	none
Growth	as written	as parent changes	as clone is written

The mistake that matters

A snapshot is not a backup. It lives in the same pool, on the same OSDs, under the same failure domains as the image it protects. It protects against:

Accidental deletion of file contents inside the guest
A bad application upgrade
Guest-level corruption

It does not protect against:

Pool deletion
Cluster loss
Correlated OSD failure taking the underlying data
An operator deleting the image, which deletes its snapshots with it

For actual backup, the data must leave the pool:

# export to a file elsewhere
rbd export rbd-vms/vm-disk-01@daily /backup/vm-disk-01-2026-08-18.img

# incremental export against a previous snapshot
rbd export-diff --from-snap daily-2026-08-17 \
    rbd-vms/vm-disk-01@daily-2026-08-18 /backup/incr-2026-08-18.diff

# or mirror to another cluster
rbd mirror image enable rbd-vms/vm-disk-01 snapshot

Choosing

Requirement	Use
Roll back a bad change quickly	snapshot
Provision many similar volumes fast	clone
Independent copy in the same cluster	`rbd cp`, or clone then flatten
Protection from cluster loss	export or mirror
Long-term retention off-cluster	export-diff to external storage

Quiz

Knowledge check · 4 questions

Q1. An RBD image is deleted. What happens to its snapshots?

They persist in the pool and can still be restored later with rbd snap restore They are converted into standalone read-only images in the same pool They remain in the pool's trash until rbd trash purge removes them They are deleted with the image — snapshots have no independent existence
Q2. A snapshot can be mounted directly as a read-only block device without creating a clone.

True False
Q3. Correct a backup strategy built on snapshots.

A team keeps 30 daily snapshots of every production RBD volume and describes this as their backup strategy. They have never exported anything off the cluster. The volumes and snapshots all live in one pool.
Q4. Why is a clone dependent on its parent while an `rbd cp` result is not?

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

Production discipline

State explicitly, in the backup documentation, which failure modes snapshots cover and which they do not — the word “backup” invites an assumption that is wrong in exactly the scenario that matters. Test restores from off-cluster copies rather than only their creation; an untested restore is not a recovery capability.

Cross-course references

Kubernetes: VolumeSnapshots share the same in-cluster limitation as RBD snapshots
Linux: LVM and ZFS snapshots carry the identical caveat about living on the same media