Full RBD export: mechanics and cost

Intermediate⏱ ~18 minrbd

What you'll learn

Export an image to a portable file
Understand what the export contains
Manage export duration and load
Store exports sensibly

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

A full export is the simplest off-cluster copy and it is the one whose duration and load surprise people at production image sizes.

Exporting

# Substitute your own values before running:
POOL=rbd
IMAGE=image01

rbd snap create "$POOL/$IMAGE@backup-$(date +%Y%m%d)"
rbd export "$POOL/$IMAGE@backup-20260818" /backups/image01.raw

# straight to a remote host without landing locally
# Substitute your own values before running:
POOL=rbd
IMAGE=image01

rbd export "$POOL/$IMAGE@backup-20260818" - | \
  ssh backup-host 'cat > /backups/image01.raw'

# compressed in flight, for sparse or compressible images
# Substitute your own values before running:
POOL=rbd
IMAGE=image01

rbd export "$POOL/$IMAGE@backup-20260818" - | \
  zstd -T0 -3 | ssh backup-host 'cat > /backups/image01.raw.zst'

Always export from a snapshot, not the live image. Exporting a live
image reads a moving target.

What the export contains

Property	In the export
The image data	yes, as a flat raw image
Sparseness	preserved where the destination supports it
Snapshots	no — one snapshot’s state only
Image metadata and features	no
The image name	no; it is a file

ls -lh /backups/image01.raw
du -h --apparent-size /backups/image01.raw
du -h /backups/image01.raw

The apparent size is the provisioned size; the actual size reflects
sparseness if the filesystem preserved it.

# what will actually be read
# Substitute your own values before running:
POOL=rbd
IMAGE=image01

rbd du "$POOL/$IMAGE@backup-20260818"

Duration and load

Export duration ≈ used size / read throughput, bounded by whichever of
the cluster, the network, or the target is slowest.

# Substitute your own values before running:
POOL=rbd
IMAGE=image01
SNAP=backup-20260818

time rbd export "$POOL/$IMAGE@$SNAP" /dev/null

Bottleneck	Signal
Cluster read	OSD latency rises during the export
Network	transfer rate plateaus below cluster capability
Target write	the target’s disk is saturated
Single-stream limit	one export uses limited parallelism

# limit the impact on the cluster
# Substitute your own values before running:
POOL=rbd
IMAGE=image01
SNAP=backup-20260818

rbd export --rbd-concurrent-management-ops 4 "$POOL/$IMAGE@$SNAP" /backups/img.raw

# watch the impact while it runs
# Substitute your own pool name before running:
POOL=rbd

watch -n 10 "ceph osd pool stats $POOL; ceph osd perf | head -5"

A full export of a large pool's images, run in parallel, is a
significant read load. Staggering them across the window is usually
better than running them concurrently.

Storing exports

Consideration	Practice
Naming	pool, image, snapshot, and date in the filename
Sparseness	store on a filesystem that preserves holes
Compression	worthwhile for most images; measure first
Integrity	checksum on write, verify on read
Retention	as decided by detection delay, not convenience

# Substitute your own values before running:
POOL=rbd
IMAGE=image01
SNAP=backup-20260818

rbd export "$POOL/$IMAGE@$SNAP" - | tee >(sha256sum > /backups/img.sha256) | \
  ssh backup-host 'cat > /backups/pool_image01_20260818.raw'

# verify what arrived
ssh backup-host 'sha256sum /backups/pool_image01_20260818.raw'
cat /backups/img.sha256

Quiz

Knowledge check · 4 questions

Q1. What determines how long an `rbd export` takes?

The used size — RBD is thin, so the export reads only the objects that exist The provisioned image size, since the export walks the address space end to end The number of snapshots on the image, since each one is read and written in turn The replication factor, since every replica is read and compared before it is written
Q2. An export taken from a live image is worse than a crash-consistent copy, not equivalent to one.

True False
Q3. Plan a full export window.

Forty RBD images totalling 30 TiB provisioned need nightly off-cluster exports. The backup window is six hours.
Q4. What does an `rbd export` file not contain?

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

Production discipline

Plan export windows against rbd du used size rather than provisioned size — RBD is thin and the difference is often large. Always snapshot first; a live export reads a moving target and produces a file corresponding to no moment in time.

Cross-course references

Kubernetes: volume snapshot before export applies identically
Linux: thin-provisioned copies transfer allocated extents, not the address space