Rollback versus clone: choosing the recovery shape

Why this matters in production

Rollback discards everything since the snapshot; clone preserves it. The choice is usually made under pressure and is hard to reverse.

The two paths

# rollback: destructive, in place
POOL=rbd-vms
IMAGE=vm-disk-01
SNAP=backup-20260818
rbd snap rollback ${POOL}/${IMAGE}@${SNAP}

# clone: additive, needs a protected snapshot
POOL=rbd-vms
IMAGE=vm-disk-01
SNAP=backup-20260818
rbd snap protect ${POOL}/${IMAGE}@${SNAP}
rbd clone ${POOL}/${IMAGE}@${SNAP} ${POOL}/${IMAGE}-recovered

The client must have the image unmapped and the VM stopped for a
rollback. Rolling back an image a guest is actively using corrupts what
the guest has in memory about it.

Performing a rollback safely

# 1. stop everything using the image
DOMAIN=vm-db-01
POOL=rbd-vms
IMAGE=vm-disk-01
virsh shutdown ${DOMAIN}
rbd status ${POOL}/${IMAGE}       # confirm no watchers

# 2. preserve the current state before discarding it
POOL=rbd-vms
IMAGE=vm-disk-01
rbd snap create "${POOL}/${IMAGE}@pre-rollback-$(date +%Y%m%d-%H%M)"

# 3. roll back
POOL=rbd-vms
IMAGE=vm-disk-01
TARGET_SNAP=backup-20260818
rbd snap rollback ${POOL}/${IMAGE}@${TARGET_SNAP}

# 4. verify before restarting the workload
POOL=rbd-vms
IMAGE=vm-disk-01
DOMAIN=vm-db-01
rbd map ${POOL}/${IMAGE}
mount -o ro /dev/rbd/${POOL}/${IMAGE} /mnt/check && ls /mnt/check
umount /mnt/check && rbd unmap /dev/rbd/${POOL}/${IMAGE}
virsh start ${DOMAIN}

Step 2 is what makes an irreversible operation reversible. It costs
seconds and it is the step most often skipped.

Performing a clone

POOL=rbd-vms
IMAGE=vm-disk-01
SNAP=backup-20260818
rbd snap protect ${POOL}/${IMAGE}@${SNAP}
rbd clone ${POOL}/${IMAGE}@${SNAP} ${POOL}/${IMAGE}-recovered
rbd info ${POOL}/${IMAGE}-recovered | grep parent

# mount the clone and take what is needed
POOL=rbd-vms
IMAGE=vm-disk-01
rbd map "${POOL}/${IMAGE}-recovered"
mount "/dev/rbd/${POOL}/${IMAGE}-recovered" /mnt/recovered
cp -a /mnt/recovered/needed-file /restore-target/

A clone is the right answer when only part of the snapshot's content is
needed — copying one file out of a clone leaves the live image
untouched.

Choosing

When in doubt, clone. It preserves the option to roll back afterwards;
rolling back does not preserve the option to clone.

A clone that becomes permanent

# a clone depends on its parent snapshot, which cannot be removed
POOL=rbd-vms
IMAGE=vm-disk-01
SNAP=backup-20260818
rbd snap unprotect ${POOL}/${IMAGE}@${SNAP}   # fails while clones exist
rbd children ${POOL}/${IMAGE}@${SNAP}

# flatten to break the dependency
POOL=rbd-vms
IMAGE=vm-disk-01
SNAP=backup-20260818
rbd flatten ${POOL}/${IMAGE}-recovered
rbd info ${POOL}/${IMAGE}-recovered | grep -c parent || echo "independent"
rbd snap unprotect ${POOL}/${IMAGE}@${SNAP}

Flattening copies the parent's data into the clone, so it consumes full
capacity — which is the cost of making the clone independent.

Quiz

Production discipline

Clone when in doubt — it preserves the option to roll back afterwards, while rolling back does not preserve the option to clone. Always take a pre-rollback snapshot; the operation discards everything since the target with no undo.

Cross-course references

• Kubernetes: restoring to a new PVC preserves the original the same way
• Linux: prefer the additive recovery path when the correct source is uncertain