When Should You Reseed a Broken ZFS Replication Chain?
Reseed when you cannot prove a valid common base or when repairing the chain would require an unverified rollback of the destination. Preserve the last readable replica first.
In a home NAS, the tempting shortcut is to force the next incremental send until it runs. That can hide a missing parent snapshot, a divergent destination, or a receive target that is no longer the dataset you think it is. Begin by inventorying both sides without changing either one, prove whether a shared base still exists, and use a staged full seed when the evidence does not support a safe incremental continuation.
Prove That Both Sides Still Share the Same Base
Start with a read-only inventory of the source dataset, destination dataset, snapshots, bookmarks, and any receive-resume state. Match more than a convenient snapshot name: confirm that the candidate base belongs to the intended datasets and represents the same replication history. Save the listings before cleanup so you can explain why the next action was chosen.
Incremental ZFS replication depends on a base already present at the receiver. A practical snapshot replication sequence therefore preserves shared history deliberately instead of assuming that identical labels prove continuity.
If a verified base exists on both sides, continue to a non-destructive incremental test. If the name exists but the identity or dataset path differs, treat the chain as unproven. If no common base remains, do not delete more snapshots or force the destination backward; the decision has already moved toward a staged reseed.
Test the Incremental Plan Without Changing the Replica
Build the proposed send with the verified base and newest target, but do not pipe it into the live destination yet. Use a dry-run, verbose estimate, or the replication tool's preview mode. Confirm the source path, destination path, base snapshot, target snapshot, recursion flags, and expected stream size before any receive can modify data.
A scheduler that reports no common base snapshot is refusing an unsafe guess, not merely asking for a retry. Repeated retries do not recreate deleted shared history.
A delta-sized stream from the exact base and target supports repairing the chain. A stream close to the full dataset size, an unexpected dataset, or any forced rollback requirement means the preview failed. Stop there and preserve the current replica; changing flags until the command runs is not verification.
Choose Repair Only When History and Destination State Agree
Repair the incremental path only when the common base is verified, the destination has not become an independent working copy, and the preview proposes the expected delta. Keep the destination read-only during the repair window. Send to a new child dataset or staging target first when the tool permits, then compare before promoting it.
Reseed when no valid base exists, the destination has diverged, the required rollback would discard snapshots you still need, or the time spent proving the chain exceeds the controlled cost of a new full transfer. Discussions of incremental snapshot ancestry reinforce that intermediate names are less important than retaining a usable common point.
Do not erase the old destination to make space unless another verified copy exists. A safer reseed writes to a separate dataset or pool, verifies the new copy, and only then retires the broken chain. If there is not enough capacity to hold both, pause and obtain temporary space rather than turning the last readable replica into the experiment.
Validate the New Chain Across Two Replication Cycles
One successful full receive proves only that a stream arrived. Create a small test file or property change on the source, take the next scheduled snapshot, and run a second incremental cycle using the new common base. Compare dataset properties, snapshot lists, a sample of files, and the replication log after both runs.
If resume behavior was part of the original failure, keep the earlier resume-token failure path separate from missing ancestry so the same symptom does not send you back to the wrong repair.
Recovery passes when the new seed is readable, the second incremental transfer is delta-sized and successful, and the expected snapshots and files appear after a reboot or scheduled run. Keep the former replica until those checks pass. Escalate if identities change again, the destination cannot remain read-only, or the tool repeatedly selects an unexpected base.
Recommended products
Support & Tips
More to Read
How to Schedule Restic Backup, Forget, and Prune Jobs Without Lock Conflicts
A complete multi-host Restic schedule that separates frequent backups, scoped retention, physical prune, checks, retries, and restore validation.
How to Prevent Restic Prune Jobs From Blocking Scheduled Backups
A prevention plan for shared Restic repositories that separates backup windows from prune and keeps locking, retries, and alerts intact.
How to Clear a Stale Restic Lock Without Interrupting an Active Backup
A least-invasive Restic unlock workflow that protects active backups, removes only stale state, and confirms recovery under the normal schedule.
