Account for OpenZFS checkpoint restrictions before a pool change

Check topology restrictions and retained space before relying on an OpenZFS pool checkpoint.

Source facts

OpenZFS 2.3 pool checkpoints preserve a pool state that can later be selected through checkpoint rewind at import. While a checkpoint exists, several topology-changing commands are prohibited, including remove, attach, detach, split, and reguid. A checkpoint can also consume space in ways that break reservation boundaries when the pool lacks free capacity. Pool status shows checkpoint existence or discard progress, and pool listing reports its space usage. Discarding a checkpoint is a separate operation.

Source: OpenZFS 2.3 — zpool checkpoint.

Applicability

This applies to OpenZFS 2.3 pool checkpoints. It addresses their operational restrictions and capacity effect, rather than ordinary dataset snapshots or an independent off-pool backup.

DSE recommendation

DSE recommends reviewing the next planned storage operation before creating a checkpoint. Record why the checkpoint is needed, who owns the decision to retain or discard it, and how its space usage will be monitored. Include prohibited topology changes in the change worksheet so an emergency expansion or replacement plan is not based on an unavailable command. Keep recovery copies independent of this convenience mechanism, and do not retain a checkpoint indefinitely without a capacity review.

Verification

In a disposable pool, create a checkpoint, inspect status and space reporting, and confirm the relevant command restrictions. Rehearse discarding it and observing completion. Document the separate review required before any rewind that would abandon later changes; do not experiment with that action on production data.

Official reference

OpenZFS 2.3 — zpool checkpoint. Reviewed October 15, 2026.