How to Verify That ZFS Replication Can Resume After an Interrupted Transfer

Yes, when the receive side preserves a valid resume token and the source snapshots needed by that token still exist.

The decision matters when a raw or incremental zfs send is interrupted by a network or destination outage. The two competing states are valid receive resume token and missing token or destroyed source snapshot. Begin with a saved configuration and disposable data, observe one branch at a time, and stop if the test expands data-loss, permission, or availability risk.

Define the Conditions Behind the Resumable Zfs Replication Decision

Record the environment before changing anything: software and firmware versions, device identities, mount or network path, free space, permissions, and the observable symptom. The baseline must preserve enough detail to reproduce a raw or incremental zfs send is interrupted by a network or destination outage.

The first candidate is valid receive resume token. The second is missing token or destroyed source snapshot. The current resumable zfs send defines the mechanism or command boundary used in the test; it does not replace observation from this specific home server.

Write the acceptance condition and stop condition before running the discriminator. A pass must change the evidence predicted by one branch while leaving unrelated services unchanged; a fail must return the system to the saved state rather than trigger a chain of speculative fixes.

Test the Claim Without Lowering the Original Requirement

Use this discriminator: interrupt a disposable replication, read the token, generate a resumed send stream, and compare the final destination snapshot. Keep workload, client, path, file set, and timing constant so the result is attributable to the changed variable.

Use ZFS send and receive to select the field that can actually separate the branches, then capture its timestamp, exit status, error text, device or snapshot identity, latency, transferred bytes, permissions, and recovery state. A clean command exit is not enough when identity, durability, or application state is the claim under test.

Repeat the test once after a restart, reconnect, remount, or cold cache when that event is part of the original condition. If the first run is destructive or the environment cannot be restored, stop and reproduce on a disposable copy instead.

token=$(zfs get -H -o value receive_resume_token pool/dst)
zfs send -t "$token" | ssh nas zfs receive pool/dst

Interpret Pass, Fail, and Exception Results

PASS: the resume stream completes and source and destination snapshots share the expected GUID lineage. Record the exact version, identity, and workload that passed so the conclusion stays conditional rather than becoming a universal claim.

FAIL: no token exists, the destination was rolled back, or required source snapshots were removed. A fail does not automatically prove the opposite branch when network, memory, permissions, or source consistency can influence both; isolate those shared dependencies before escalating.

EXCEPTION OR AMBIGUOUS RESULT: abort the partial receive only after deciding that restart cost is acceptable. Preserve logs and do not run repair, prune, destroy, repartition, or recursive ownership commands until a recoverable copy exists.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Confirm the Decision Under the Original Workload

Apply the action matched to the observed branch, then repeat the original condition rather than a reduced substitute. The decision holds only when the resume stream completes and source and destination snapshots share the expected GUID lineage across two cycles or the relevant reboot, sleep, interruption, or load transition.

Use the immutable backup windows to check the nearest dependent workflow, but keep the original trigger unchanged. Unrelated datasets, shares, containers, users, and recovery points must retain their previous access and timing.

The stop boundary is explicit: if no token exists, the destination was rolled back, or required source snapshots were removed, return to the last verified configuration, retain the evidence, and escalate to a deeper platform or hardware test only when the branch is repeatable.

After the target result holds, compare it with the local repository layout so the fix does not move risk into a neighboring service. A successful target test with a new backup, identity, timeout, or availability failure is still a failed change.

FAQ

For resumable ZFS replication, the remaining searches usually concern does every interrupted receive create a token, can old source snapshots be deleted after interruption, and how do you verify the final replica. The answers below keep those edge cases separate from the primary decision.

The acceptance boundary does not move: the resume stream completes and source and destination snapshots share the expected GUID lineage. If a follow-up condition changes the filesystem, identity, network path, or application version, repeat only the discriminator affected by that change.

Stop broadening the experiment when no token exists, the destination was rolled back, or required source snapshots were removed. At that point, abort the partial receive only after deciding that restart cost is acceptable; preserve the evidence before escalating to the platform, storage, or hardware owner.

Does every interrupted receive create a token?

No. The receive must use resumable behavior and fail in a state that preserves a token.

Can old source snapshots be deleted after interruption?

Not until the resumed stream no longer depends on them and the destination has been verified.

How do you verify the final replica?

Compare snapshot GUID lineage, properties, expected files, and a restore sample—not only command exit status.

For resumable ZFS replication, the practical answer remains conditional: the resume stream completes and source and destination snapshots share the expected GUID lineage. When no token exists, the destination was rolled back, or required source snapshots were removed, abort the partial receive only after deciding that restart cost is acceptable; a partial success that cannot survive the original workload is not compatibility.