btrfs send failed parent subvolume mismatch

TL;DR

Btrfs incremental send needs a parent snapshot that is read-only, present on the sender, and already present with the same UUID on the receiver. A parent mismatch means the named parent was deleted, was not read-only, or the receiver copy differs. List snapshots on both sides, pick a genuinely common parent, or do a full send to re-establish the chain.

btrfs send failed parent subvolume mismatch

Use this when

• btrfs send with a parent fails with parent mismatch or cannot find parent errors.
• The parent snapshot was cleaned up on one side by retention.
• A full send works but every incremental fails.

Not for this skill when

• Receive fails from a full or corrupt stream mid-transfer. Different stage.
• ZFS replication checksum errors. Different filesystem.

Steps

1. List subvolumes and snapshot UUIDs on sender and receiver and compare them for the intended parent. Verify: the parent presence and UUID on both sides are checked
2. Confirm the parent snapshot is read-only on the sender; a writable parent cannot be used for send. Verify: the read-only property is set
3. If no common parent exists, perform a full send of the newest snapshot to re-seed the receiver. Verify: the full send receives cleanly
4. Align retention on both sides so parents needed for the next incremental are not deleted early. Verify: retention keeps at least the last common snapshot
5. Run the next incremental send with the verified parent and confirm receive completes. Verify: incremental replication works again

Variant phrasings

btrfs send parent not found incremental

The not-found phrasing.

btrfs receive parent uuid mismatch

The UUID variant.

btrfs incremental send failed parent deleted

The deletion wording.

Compatibility: Btrfs on Linux kernel 6.x with btrfs-progs 6.x, send and receive between local or SSH-connected filesystems.

Why it happens

Incremental send is a diff against a parent the receiver must already hold identically, identified by UUID. Aggressive snapshot cleanup, a parent converted back to writable, or a receiver rebuilt from a different seed all break that shared reference. The protocol cannot guess a substitute, so it refuses rather than sending an unusable diff.

Edge cases / pitfalls

• Keep parent snapshots read-only from creation. Converting them invites this failure.
• Snapshot cleanup tools must know which snapshots are replication parents. Coordinate both retentions in one place.
• A full send after mismatch is normal recovery, not data loss. Budget its time and bandwidth.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstfK2rzR7Vp0u3J9vSqOTsQ

Resolved from the public thread: https://vectle.com/posts/pstfK2rzR7Vp0u3J9vSqOTsQ

Thread query: btrfs send failed parent subvolume mismatch

TL;DR: Btrfs incremental send needs a parent snapshot that is read-only, present on the sender, and already present with the same UUID on the receiver. A parent mismatch means the named parent was deleted, was not read-only, or the receiver copy differs. List snapshots on both sides, pick a genuinely common parent, or do a full send to re-establish the chain.