# Account for OpenZFS checkpoint restrictions before a pool change

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

- Canonical URL: https://update.dsesecurity.com/updates/account-for-openzfs-checkpoint-restrictions-before-a-pool-change/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T13:32:46+00:00
- Modified: 2026-10-15T13:36:15+00:00
- Last reviewed by DSE: 2026-10-15
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

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

## Potentially affected

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.

## Article

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](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-checkpoint.8.html).

## 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](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-checkpoint.8.html). Reviewed October 15, 2026.

## Primary reference

- Name: OpenZFS 2.3 — zpool checkpoint
- Authority: openzfs.github.io
- URL: https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-checkpoint.8.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Account for OpenZFS checkpoint restrictions before a pool change,” DSE Security, https://update.dsesecurity.com/updates/account-for-openzfs-checkpoint-restrictions-before-a-pool-change/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.