There are two kinds of storage engineers: the ones who’ve needed an emergency reverse gear, and the ones who haven’t needed it yet. ZFS zpool checkpoint is that reverse gear: a pool-wide “undo” point that can roll back the on-disk state of a pool to a moment in time. It’s not a backup. It’s not a snapshot. It’s not even particularly forgiving. But in the right window, it can turn a career-limiting mistake into a mildly embarrassing change ticket.
If you treat checkpoints like “free safety,” you’ll eventually discover their favorite party trick: making space disappear at the exact moment you most need it. This is an operational tool, not a comfort blanket. Let’s talk about how it works, what it’s good for, why it’s dangerous, and how to use it in production without becoming an anecdote.
What a zpool checkpoint is (and is not)
A ZFS pool checkpoint is a special marker stored in the pool metadata that lets you roll the entire pool back to the exact on-disk state at the time the checkpoint was taken. Not “restore some files.” Not “revert one dataset.” The whole pool: datasets, snapshots, block pointers, allocations—everything.
Checkpoints are best understood as a “pool-wide rewind button” that relies on ZFS’s copy-on-write (CoW) nature. After you create a checkpoint, ZFS must preserve the old state so it can be reconstructed. That means blocks that were previously free can no longer be reused if they are needed to keep the checkpoint consistent. The practical consequence is brutal: a checkpoint can pin space. On a busy pool, that pinned space can grow rapidly, and it grows in the worst possible way: silently, until it’s not silent anymore.
What it is
- A pool-level rollback point for the entire pool’s metadata and data.
- One checkpoint at a time (per pool), not an unlimited stack.
- A tactical tool for risky operations: pool upgrades, device replacement choreography, on-disk feature changes, major refactors.
What it is not
- Not a backup. If the pool dies, the checkpoint dies with it.
- Not a dataset snapshot. Snapshots are per-dataset and can be sent/received; checkpoints cannot.
- Not selective. You can’t roll back one dataset and keep others “as of now.”
First joke (as promised, short): A checkpoint is like “undo” in a text editor—except it also undoes your coworker’s changes, your CI pipeline’s changes, and your last two hours of sanity.
Why checkpoints exist: a brief history and some facts
Checkpoints feel like a modern convenience, but they’re rooted in old ZFS truths: metadata is sacred, and CoW is both a superpower and a liability. Here are some facts and context points that help explain why checkpoints exist and why they’re shaped the way they are.
- ZFS’s original promise (mid-2000s era) was “end-to-end data integrity,” and CoW is a core mechanism: new writes don’t overwrite old blocks; they allocate new blocks and then atomically swing pointers.
- Pool feature flags evolved as ZFS left its original vendor ecosystem and spread across implementations. Some features are “active” only once used; others change how on-disk structures behave. Rolling back after enabling or using features can be complicated.
- zpool upgrade used to be scarier when feature activations were less transparent to operators. Checkpoints arrived as a safety net for “I upgraded and now regret it” moments.
- Snapshots are cheap until they aren’t: as snapshots proliferated, operators learned “cheap” refers to metadata, not to forever pinned blocks on a high-churn dataset. Checkpoints carry the same physics—just at pool scale.
- Space accounting in ZFS is subtle. “df says plenty free” is not the same as “ZFS can allocate.” Checkpoints add another reason those numbers can diverge.
- High fragmentation is survivable, but high fragmentation while near-full is where pools get unstable in human terms (slow, failure-prone operationally). Checkpoints can push you closer to that cliff.
- One-checkpoint limit is intentional: the pool already has to preserve prior state; stacking multiple pool-wide historical states would amplify pinned space and complexity.
- Operational tooling grew up around the reality that production changes are messy: device swaps, ashift mismatches, feature flags, accidental destructive commands. Checkpoints exist because humans exist.
How checkpoints work under the hood
You can operate checkpoints safely without reading ZFS source, but you do need a mental model. Here’s the model that maps to real-world symptoms.
The checkpoint is a “saved pool root”
ZFS has a concept of a pool state rooted in metadata structures (think of an “uberblock” as one of the entry points to “what is the pool right now”). A checkpoint effectively preserves a prior root so ZFS can traverse the old tree of block pointers and reconstruct the old view.
Why space vanishes: blocks become non-reusable
Because ZFS is CoW, the checkpoint doesn’t need to copy the entire pool. It just needs the old blocks to remain reachable. But if you modify data after the checkpoint, ZFS writes new blocks. The old blocks remain referenced by the checkpoint, and therefore cannot be freed. If you delete data after the checkpoint, you’ll feel cheated: “I deleted 20 TB, why didn’t I get space back?” Because from the checkpoint’s point of view, that data still exists and must remain restorable.
Rollback is not magic—it’s a controlled detonation
Rolling back to a checkpoint throws away everything that happened after it: all writes, all deletes, all dataset changes, and any operational progress that touched on-disk state. It can also interact with features and device operations in ways that require planning. The pool returns to its previous topology state as recorded at the checkpoint time, not as you wish it were.
The sharp edges
- Near-full pools: a checkpoint can tip you into “no space” conditions faster than you can react.
- Busy pools: churn pins blocks rapidly; a checkpoint’s “cost” can balloon in hours.
- Human coordination: you must treat a checkpoint period as a change freeze window for certain actions, or you’ll create rollback landmines.
Second joke (also short): Using a checkpoint without monitoring is like borrowing a parachute but not checking the straps—technically you’re safer, right up until physics gets an opinion.
When to use a checkpoint (and when not to)
Good use cases
1) Before a risky, pool-wide change you can’t easily unwind. Examples: enabling a feature that changes on-disk format usage, performing a pool upgrade in an environment where rollback may be demanded, or doing an unusual sequence of device operations.
2) Before a surgical operation where “undo the last 30 minutes” matters. Think of a maintenance window where you’ll be running commands that can brick the pool config if fat-fingered.
3) Before an experiment on a non-replicated pool. Sometimes you have a lab pool that behaves like prod, and you need one safe “rewind.”
Bad use cases
1) As a substitute for backups or replication. If the pool is toast, the checkpoint is toast.
2) As a long-lived safety net. A checkpoint you “leave around for a week just in case” is a classic way to discover that your pool can run out of space while your dashboards still look fine.
3) On pools that are already tight on free space. If you’re under pressure on free space, a checkpoint turns “tight” into “fragile.” You might still do it, but then your plan must include active monitoring, a hard deadline, and a quick abort path (discarding the checkpoint).
Rule of thumb
If you wouldn’t be comfortable running with effectively less free space than you have right now, don’t create a checkpoint without first creating that headroom. The checkpoint itself doesn’t necessarily consume space immediately; it consumes your ability to recover space by freeing blocks.
Practical tasks: commands, output, interpretation
Below are real operational tasks you can run on a typical Linux + OpenZFS system. Some outputs vary by version, pool features, and platform, but the intent and the interpretation hold. Commands assume the pool is named tank.
Task 1: Confirm pool health before doing anything
cr0x@server:~$ sudo zpool status -xv tank
pool 'tank' is healthyInterpretation: If the pool isn’t healthy, don’t add “checkpoint complexity” to an already unstable situation. Fix faults, complete resilvers, and address errors first.
Task 2: Record a “before” snapshot of state for your change ticket
cr0x@server:~$ date -Is
2025-12-25T10:18:44+00:00
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 02:14:19 with 0 errors on Thu Dec 19 03:10:14 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
errors: No known data errorsInterpretation: Save this output with the change record. In incident response, the difference between “we think it was fine” and “here’s the status at 10:18 UTC” is hours.
Task 3: Check free space and fragmentation risk signals
cr0x@server:~$ sudo zpool list -o name,size,alloc,free,capacity,fragmentation,health tank
NAME SIZE ALLOC FREE CAP FRAG HEALTH
tank 72T 58.2T 13.8T 80% 41% ONLINEInterpretation: 80% full with 41% fragmentation is workable, but it’s not “plenty.” A checkpoint can make deletes stop helping. If you’re already north of ~85–90% capacity, treat a checkpoint as hazardous.
Task 4: Verify whether a checkpoint already exists
cr0x@server:~$ sudo zpool get checkpoint tank
NAME PROPERTY VALUE SOURCE
tank checkpoint - -Interpretation: A value of - means no checkpoint is present. If you see a timestamp or non-empty value, you already have one and you need to decide whether to keep it, discard it, or roll back to it.
Task 5: Create a checkpoint (and log exactly when you did it)
cr0x@server:~$ sudo zpool checkpoint tank
cr0x@server:~$ sudo zpool get checkpoint tank
NAME PROPERTY VALUE SOURCE
tank checkpoint 2025-12-25T10:22:11+00:00 -Interpretation: That timestamp is your “point of no return” for everything that happens afterward. Write it down where humans will see it, not just in shell history.
Task 6: Observe pinned space behavior via freeing data (the “why didn’t free space increase?” test)
cr0x@server:~$ sudo zfs destroy -r tank/tmp/testdata
cr0x@server:~$ sudo zpool list -o name,alloc,free,capacity tank
NAME ALLOC FREE CAP
tank 58.2T 13.8T 80%Interpretation: If alloc/free barely move after a big delete and you have a checkpoint, you’ve learned the key operational truth: deletes don’t necessarily buy headroom until the checkpoint is gone.
Task 7: Check dataset-level space view to avoid “df panic”
cr0x@server:~$ df -h /tank
Filesystem Size Used Avail Use% Mounted on
tank 72T 58T 14T 81% /tank
cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint tank
NAME USED AVAIL REFER MOUNTPOINT
tank 58.2T 12.9T 256K /tankInterpretation: df and zfs list often agree at the top level, but during checkpoint periods you can encounter situations where application behavior suggests “out of space” earlier than expected because ZFS allocation realities get tighter than userland expects.
Task 8: Confirm you didn’t accidentally “upgrade and activate” something you can’t roll back from
cr0x@server:~$ sudo zpool get all tank | egrep 'feature@|compatibility|readonly'
tank readonly off default
tank compatibility off default
tank feature@async_destroy enabled local
tank feature@spacemap_histogram active local
tank feature@extensible_dataset enabled localInterpretation: “Enabled” means available; “active” means used in the on-disk state. A checkpoint can help you roll back some categories of “I changed my mind,” but feature activation can complicate interop and downgrade paths. Don’t guess—inspect.
Task 9: Dry-run your rollback decision by enumerating “what would be lost”
cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank/home@autosnap_2025-12-25_0900 Thu Dec 25 09:00 2025
tank/home@autosnap_2025-12-25_1000 Thu Dec 25 10:00 2025
tank/db@prechange_2025-12-25_1015 Thu Dec 25 10:15 2025
tank/db@postchange_2025-12-25_1030 Thu Dec 25 10:30 2025
tank/logs@hourly_2025-12-25_1100 Thu Dec 25 11:00 2025Interpretation: Snapshots created after the checkpoint will be lost if you roll back the pool. Make your rollback decision with eyes open, and warn stakeholders: “you will lose everything since 10:22.”
Task 10: Roll back to the checkpoint (the big hammer)
cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import tank
cr0x@server:~$ sudo zpool checkpoint -r tankInterpretation: Rolling back is disruptive and should be treated like a maintenance event. Export/import isn’t always strictly required for rollback, but in practice it’s a clean way to ensure services are down, mounts are quiesced, and you’re not rolling back under active writes. After rollback, the checkpoint is typically cleared because you’ve returned to it.
Task 11: Discard the checkpoint (commit to the new world and reclaim reuse)
cr0x@server:~$ sudo zpool checkpoint -d tank
cr0x@server:~$ sudo zpool get checkpoint tank
NAME PROPERTY VALUE SOURCE
tank checkpoint - -Interpretation: This is the “we’re done, keep the changes” step. Operationally, discarding is often the most important checkpoint action—because it restores normal space reuse. Set a deadline for this step when you create the checkpoint.
Task 12: Watch for space pressure while a checkpoint exists
cr0x@server:~$ watch -n 5 'zpool list -o name,alloc,free,capacity,fragmentation tank; echo; zpool get checkpoint tank'
Every 5.0s: zpool list -o name,alloc,free,capacity,fragmentation tank; echo; zpool get checkpoint tank
NAME ALLOC FREE CAP FRAG
tank 60.1T 11.9T 83% 44%
NAME PROPERTY VALUE SOURCE
tank checkpoint 2025-12-25T10:22:11+00:00 -Interpretation: If alloc climbs while your change is running, you may be pinning old blocks and creating new ones. A rising capacity during a checkpoint window is normal; a rising capacity near the cliff is a reason to abort early by discarding the checkpoint or pausing churn.
Task 13: Identify heavy writers during the checkpoint window
cr0x@server:~$ sudo zpool iostat -v tank 5 3
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 60.1T 11.9T 5 802 1.20M 210M
raidz1-0 60.1T 11.9T 5 802 1.20M 210M
sda - - 1 270 410K 70.2M
sdb - - 2 265 420K 69.1M
sdc - - 2 267 370K 70.7M
-------------------------- ----- ----- ----- ----- ----- -----Interpretation: High write bandwidth during the checkpoint window means you’re accumulating “new world” data while pinning “old world” data. If you want the checkpoint to remain cheap, minimize write churn.
Task 14: Validate mountpoints and dataset health after discard/rollback
cr0x@server:~$ sudo zfs mount -a
cr0x@server:~$ sudo zfs list -o name,mounted,available,used,mountpoint tank | head
NAME MOUNTED AVAIL USED MOUNTPOINT
tank yes 12.9T 60.1T /tank
tank/home yes 12.9T 8.4T /tank/home
tank/db yes 12.9T 44.0T /tank/dbInterpretation: After a rollback, don’t assume services will come back cleanly. Mount state and dataset availability are the first “is the storage sane?” checks before you restart databases or hypervisors.
Fast diagnosis playbook: when the pool feels “weird”
This is the “it’s 02:00 and something is off” checklist. The goal is to identify whether the checkpoint is contributing to the symptom, and whether you’re facing a space, I/O, or fragmentation bottleneck.
First: establish whether a checkpoint exists and how long it has existed
cr0x@server:~$ sudo zpool get checkpoint tank
NAME PROPERTY VALUE SOURCE
tank checkpoint 2025-12-25T10:22:11+00:00 -If you have a checkpoint: treat space anomalies as “checkpoint until proven otherwise.” If you don’t, proceed as normal ZFS triage.
Second: check actual pool headroom and red flags
cr0x@server:~$ sudo zpool list -o name,alloc,free,capacity,fragmentation,health tank
NAME ALLOC FREE CAP FRAG HEALTH
tank 60.1T 11.9T 83% 44% ONLINEWhat you’re looking for: capacity creeping toward 90% while a checkpoint exists; fragmentation climbing; health not ONLINE.
Third: identify if you’re IOPS-bound, bandwidth-bound, or blocked on something else
cr0x@server:~$ sudo zpool iostat -v tank 2 5
cr0x@server:~$ sudo zpool status -v tankInterpretation:
- High writes + low free space: you’re heading toward “allocation failure” territory. Decide quickly: discard checkpoint, pause writers, or add space.
- High read latency symptoms: checkpoint isn’t usually the direct cause, but it correlates with high churn periods and fragmentation, which can amplify latency.
- Errors or resilvering: do not roll back casually during device fault activity. Stabilize first unless rollback is the only way out.
Fourth: verify whether deletes are “working”
cr0x@server:~$ sudo zpool list -o alloc,free,capacity tank
ALLOC FREE CAP
60.1T 11.9T 83%Interpretation: If you delete large datasets and free doesn’t budge during a checkpoint window, don’t keep deleting in a panic. You’re not gaining runway; you’re just making your post-checkpoint world weirder.
Three corporate-world mini-stories
1) The incident caused by a wrong assumption
They had a virtualization cluster backing store on a big ZFS pool. The storage team planned a feature flag change and, trying to be responsible, created a checkpoint “just in case.” The maintenance window was quiet. The change seemed fine. Everyone went home.
Two days later, alerts started: VMs intermittently failing writes, then a cascade of “read-only filesystem” behavior in guests. The on-call saw “15 TB free” in the dashboards and assumed it couldn’t be a space issue. They chased ghosts: multipath, HBA firmware, a suspected bad SSD in the SLOG. Everything looked mostly normal.
What actually happened was simpler and crueler. During those two days, the pool churned: VM images, logs, database churn in guests. The checkpoint pinned a growing amount of old blocks, and deletes/reclaims didn’t help. The pool wasn’t out of space by the naive “free” metric, but it was becoming allocation-hostile: fragmentation went up, metaslab free segments became less useful, and operations that required contiguous-ish allocations started failing under load.
The wrong assumption was that a checkpoint is “free until you roll back.” It isn’t. It’s a live constraint on space reuse. They discarded the checkpoint, and space behavior returned to normal within the hour. The postmortem action item was blunt: checkpoints must have an owner and an expiration time, and monitoring must flag “checkpoint older than X hours” the same way it flags a degraded vdev.
2) The optimization that backfired
A platform team decided to reduce maintenance risk by standardizing a workflow: “checkpoint before every storage change.” It sounded like maturity. The change calendar got busier, so checkpoints became frequent. Someone even scripted it: when a change ticket is approved, the automation creates the checkpoint and posts the timestamp into the chat thread.
Then came the backfire. They used the same pool for both critical databases and a large analytics workload that rewrote a ton of data daily. During a routine device replacement, the checkpoint was created and left in place longer than expected because the vendor shipped the wrong drive model and they postponed the rest of the work. Meanwhile, analytics kept hammering the pool.
The pool didn’t fail. It did something worse: it slowed down in a way that wasn’t immediately attributable. Latency climbed, replication windows slipped, and the database team started rate-limiting their own workloads to keep tail latency acceptable. The storage team looked at the checkpoint and thought, “We didn’t roll back, so it shouldn’t matter.” But it mattered because the checkpoint made the pool carry two realities at once. Writes kept allocating new blocks while old blocks stayed pinned. Space maps became more complex, fragmentation climbed, and the pool behaved like it was older and fuller than it actually was.
The fix was cultural: checkpoints became a tool used only for changes with real rollback value, not for every routine operation. They replaced “checkpoint everywhere” with “checkpoint when rollback meaningfully changes risk,” and paired it with short-lived dataset snapshots for smaller changes. The optimization failed because it optimized for the wrong metric: perceived safety, not operational stability.
3) The boring but correct practice that saved the day
A finance-adjacent system had a strict change process: every storage change required a preflight checklist, a maintenance window, and a “revert plan” written in plain language. It was boring enough that engineers complained about it—quietly, because finance systems tend to win arguments by existing.
During a planned pool upgrade, they created a checkpoint and immediately pinned an internal calendar reminder: “Discard checkpoint by end of window unless rollback required.” They also put a guardrail in monitoring: if a checkpoint exists for more than four hours, page the on-call and the change owner. It wasn’t fancy, just explicit ownership and a timer.
Halfway through the window, a storage engineer noticed a service behaving oddly. Not failing, just “off.” Because the revert plan was already written, they didn’t improvise. They paused dependent services, exported the pool, re-imported cleanly, rolled back to the checkpoint, and restored service. The post-incident review found a configuration interaction that would have been painful to unwind manually.
The save wasn’t the checkpoint alone—it was the discipline around it: quiescing writes, having a deadline, and treating rollback as a planned operation rather than an emotional reaction. The practice was boring because it was correct. Boring is underrated in storage.
Common mistakes (with symptoms and fixes)
Mistake 1: Creating a checkpoint on a near-full pool
Symptoms: pool capacity climbs rapidly; deletes don’t reclaim space; applications start throwing ENOSPC or “disk full” despite “free space” expectations; fragmentation increases.
Fix: if rollback is no longer needed, discard the checkpoint. If rollback might still be needed, pause high-churn workloads and add headroom (additional vdevs or temporary migration). In a crisis, prioritize reducing churn over deleting data—the deletes are pinned anyway.
Mistake 2: Leaving a checkpoint around “just in case”
Symptoms: slow-burning space pressure that doesn’t correlate with user-visible data growth; long-term performance degradation on random-write workloads.
Fix: enforce an expiration policy. Operationally: checkpoint must have a human owner, a removal deadline, and monitoring that alerts on age.
Mistake 3: Assuming checkpoints behave like snapshots
Symptoms: someone expects to restore a single dataset; someone tries to “send” a checkpoint; confusion about what will be lost.
Fix: educate with a rule: snapshots are per-dataset; checkpoints are pool-wide. Use snapshots for “I want my directory back.” Use checkpoints for “I want my pool back.”
Mistake 4: Rolling back without quiescing writes
Symptoms: services come back corrupted at the application level; databases require recovery; VMs may have inconsistent disks; confused blame toward ZFS.
Fix: treat rollback like restoring a storage layer image: stop services, flush buffers, unmount where possible, export/import to ensure no writers. Then rollback. ZFS will do what you asked; applications will do what physics allows.
Mistake 5: Forgetting that rollback discards operational progress
Symptoms: a device replacement “disappears,” a topology change is undone, or a carefully staged migration is reversed.
Fix: document exactly what actions occurred after the checkpoint. If you replaced a disk after the checkpoint, rolling back can revert to the earlier topology view, which can confuse subsequent operations. Plan rollback steps, not just the command.
Mistake 6: Interpreting “free space” as “allocatable space” under pressure
Symptoms: “we still have terabytes free” but allocations fail; performance tanks; metadata operations slow; weird latency spikes.
Fix: watch pool capacity and fragmentation, and keep more headroom than you think you need—especially during a checkpoint window. Consider temporary throttling of writers and ensure autotrim (where appropriate) isn’t masking device-level behavior.
Checklists / step-by-step plan
Checklist A: Creating a checkpoint safely (production)
- Confirm health: pool ONLINE, no resilver in progress unless you have a very specific reason.
- Confirm headroom: check capacity and fragmentation; if you’re above comfortable thresholds, create headroom first.
- Define the rollback scope: what exactly would rollback undo? Write it down in the change record.
- Set an expiration time: “discard by end of window” is a good default. Longer windows need justification and monitoring.
- Create the checkpoint: record timestamp.
- Monitor during the window: watch alloc/free and write rates. If space pressure rises, decide early.
- End the window with intent: either discard (commit) or roll back (revert). Don’t leave it ambiguous.
Checklist B: Discarding a checkpoint (the most forgotten step)
- Verify services are healthy and the change is accepted.
- Confirm the checkpoint exists.
- Discard it.
- Verify it is gone.
- Watch pool free space behavior for the next hour: deletes should reclaim again, and alloc growth should reflect reality.
cr0x@server:~$ sudo zpool get checkpoint tank
NAME PROPERTY VALUE SOURCE
tank checkpoint 2025-12-25T10:22:11+00:00 -
cr0x@server:~$ sudo zpool checkpoint -d tank
cr0x@server:~$ sudo zpool get checkpoint tank
NAME PROPERTY VALUE SOURCE
tank checkpoint - -Checklist C: Rolling back safely (when you really mean it)
- Declare impact: everything after the checkpoint timestamp will be lost.
- Quiesce: stop applications, unmount or remount read-only if applicable.
- Export/import: ensures a clean, consistent pool import state without active writers.
- Rollback: run checkpoint rollback.
- Validate: mount datasets, check pool health, then bring services up in controlled order.
cr0x@server:~$ sudo systemctl stop libvirtd
cr0x@server:~$ sudo systemctl stop postgresql
cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import tank
cr0x@server:~$ sudo zpool checkpoint -r tank
cr0x@server:~$ sudo zpool status -xv tank
pool 'tank' is healthyFAQ
1) Is a zpool checkpoint the same as a ZFS snapshot?
No. Snapshots are per-dataset and let you restore or clone dataset state. A checkpoint is a pool-wide rollback point that rewinds everything on the pool, including all datasets and their snapshots.
2) Can I have multiple checkpoints?
Typically, no: one checkpoint at a time per pool. The limitation is partly to prevent pinned-space and complexity from becoming unmanageable.
3) Does creating a checkpoint immediately consume space?
It usually doesn’t allocate a huge amount immediately. The cost shows up as you modify data afterward: old blocks that would normally become free stay pinned so the checkpoint can be reconstructed.
4) Why didn’t free space increase after I deleted terabytes?
Because the checkpoint still references the old blocks. From the checkpoint’s point of view, the data still exists. Discarding the checkpoint removes that constraint and allows normal space reuse.
5) Can I “send” a checkpoint to another machine like a snapshot?
No. If you need portability, use dataset snapshots with zfs send/zfs receive, or replicate the pool via other means. A checkpoint is not a replication mechanism.
6) Should I create a checkpoint before zpool upgrade?
Sometimes. If you’re in an environment where rollback might be demanded and you have enough headroom, it can be a reasonable hedge. But the best “upgrade safety” remains: test in staging, understand feature flags, and have real backups/replication. A checkpoint is a tactical undo, not a strategy.
7) Will a checkpoint protect me from hardware failure during the change?
No. A checkpoint doesn’t make a second copy of your data. If you lose the pool or enough devices to make it unavailable, the checkpoint goes down with it.
8) Is it safe to keep a checkpoint for days?
It can be safe in the sense that ZFS supports it, but it’s operationally risky on active pools. You’re betting that pinned blocks and fragmentation won’t push you into space pressure or performance issues. If you must keep it, monitor aggressively and set a firm expiration.
9) Does rollback fix application-level corruption?
It can undo storage-level changes, but it doesn’t guarantee application consistency unless you quiesced the application at checkpoint time and at rollback time. Databases, VMs, and distributed systems care about write ordering and flush semantics, not just blocks on disk.
10) What’s the simplest safe policy for checkpoints in production?
Use them only for changes where pool-wide rollback is genuinely valuable, always attach an owner and a deadline, and default to discarding them at the end of the maintenance window.
Conclusion
zpool checkpoint is one of those features that feels like a gift until you learn its price tag. It’s a pool-wide emergency undo, powered by CoW, and it works—often spectacularly well—when you use it for short, controlled windows. The sharp edges come from the same place its power comes from: preserving the past means the pool can’t freely reuse the present.
If you remember only three things, make it these: (1) a checkpoint is not a backup, (2) it can pin space and quietly wreck your headroom, and (3) the safest checkpoint is the one with a written owner, a timer, and a clear end-of-window decision: discard or roll back. In storage, ambiguity is how “temporary” becomes “permanent,” and “permanent” becomes “incident.”