Btrfs Send Parent Verification Checklist Before Snapshot Cleanup
Do not delete a Btrfs send parent because it looks old. First prove that a newer read-only snapshot exists on both sides and can serve the next incremental cycle.
On a home NAS, source and destination snapshots often have similar names while their replication roles differ. Cleanup becomes risky when a rotation job sees only age, not which pair anchors the next send. Begin with a read-only inventory, identify the last successful source-to-destination pair, test a newer child against it, and preserve the previous destination until another incremental receive completes.
Inventory the Current Parent Pair on Both Systems
List the source subvolume, every read-only send snapshot, and every received destination snapshot. Record the path, creation time, read-only state, subvolume ID, UUID, parent relationship, and received identity when available. Pair the last successful source snapshot with the copy that was actually received, not merely a similarly named directory.
A working Btrfs send and receive sequence keeps the prior snapshot available on both systems before using it as the parent of the next incremental stream.
If the pair is clearly present and read-only, mark it as protected. If only the names match, inspect the received relationship and the replication log before continuing. If the destination copy is missing, stop cleanup and plan a new full send or another verified base; deleting the source snapshot cannot repair the missing receiver history.
Prove a Newer Snapshot Can Become the Next Parent
Create the next read-only source snapshot after the inventory is saved. Use the protected source snapshot as the explicit parent and send the new child to the intended destination or a staging path. Capture the exit status and log, then compare a sample of changed and unchanged files on the received snapshot.
Incremental replication scripts should make the dependency visible. A practical snapshot rotation workflow works only when the snapshots expected by the send logic remain in place.
Promote the new pair to cleanup candidate only when the receive succeeds and the destination snapshot is readable. A parent-not-found error, writable source snapshot, wrong dataset, or stream unexpectedly equivalent to a full copy means the test failed. Keep the old pair untouched while you correct the path or rebuild the base.
Clean Up Only After the Parent Role Moves Forward
Update the retention record before deleting anything. Mark the newly verified source and destination snapshots as the active pair, keep the immediately previous pair as a short-term fallback, and preview which older snapshots the cleanup job would remove. The preview should contain only ancestors no longer needed by the next send or restore plan.
A file change can be carried into a newer snapshot and sent from an existing base, so future incremental history depends on preserved snapshot relationships rather than editing an old read-only snapshot.
Cancel cleanup if the active parent, fallback pair, newest received snapshot, or an unverified orphan appears in the deletion set. Remove snapshots in small groups and re-list both systems after each group. Do not let separate source and destination rotation jobs advance independently without sharing the same protected-pair record.
Run the Following Incremental Cycle Before Retiring the Fallback
After cleanup, create one controlled file change and a new read-only snapshot. Run the next incremental send from the newly promoted parent. This second cycle proves that the cleanup record, script, and destination state all agree; the first successful send alone did not test the post-cleanup environment.
If a snapshot cannot be removed because it remains in use, separate retention logic from the active Btrfs send path before treating the parent map as wrong.
The checklist passes when the second child receives successfully, the expected files are present, the active pair remains read-only, and the next scheduled run selects it automatically. Retire the fallback only after that result. Stop and restore the previous pair to protected status if the next send reports a missing parent, targets the wrong subvolume, or proposes an unexpected full transfer.
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.
