zfs send recv checksum mismatch

Not specified by the original author.

TL;DR

A checksum mismatch on receive means the stream ZFS received does not hash to what the sender computed, so either source data, the transport, or receiving memory and storage corrupted it. Scrub both pools, test the transport with a small snapshot, resend incrementally from a known-good common snapshot, and preserve evidence if corruption is on disk.

zfs send failed: checksum mismatch on receive

Use this when

• zfs receive aborts with checksum mismatch.
• The same send works pool to pool locally but fails over the network, or the reverse.
• Scrub on either pool reports errors near the same data.

Not for this skill when

• The send cannot start because snapshots are missing or held. Different failure.
• Btrfs send parent mismatch. Different filesystem and tooling.

Steps

1. Scrub both the sending and receiving pools and record any checksum errors and the files they name. Verify: both pool health reports are captured
2. Send a small test snapshot over the same transport and receive it, to separate transport faults from dataset faults. Verify: the test stream passes or fails
3. If the network path is implicated, resend over a direct or alternate path, avoiding proxies that can alter streams. Verify: the alternate path result is known
4. Identify the newest common snapshot that received cleanly and restart the incremental send from it. Verify: the incremental base is agreed by both sides
5. Complete the send and run a scrub plus a sample dataset comparison on the receiver. Verify: received data scrubs clean and samples match

Variant phrasings

zfs receive checksum mismatch corrupted stream

The stream phrasing.

zfs send receive checksum error network

The network variant.

zfs replication checksum mismatch fix

The replication wording.

Compatibility: OpenZFS 2.1 and 2.2 on Linux and FreeBSD, native and raw encrypted sends over SSH and local pipes.

Why it happens

ZFS checksums every block and verifies stream records on receive, giving end-to-end detection most backup tools lack. A mismatch is therefore high-quality evidence of corruption somewhere between the source blocks and the receiving pool, including faulty RAM without ECC, bad cables or HBAs, and buggy transport layers, not a software setting to tune away.

Edge cases / pitfalls

• Never force receive past checksum errors. You would import proven-bad data.
• Repeated mismatches on one host pair with clean scrubs suggest memory faults. Run memory tests.
• Keep the failing stream file if you captured one. It is the best evidence for vendor or hardware diagnosis.

Provenance

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

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

Thread query: zfs send failed: checksum mismatch on receive

TL;DR: A checksum mismatch on receive means the stream ZFS received does not hash to what the sender computed, so either source data, the transport, or receiving memory and storage corrupted it. Scrub both pools, test the transport with a small snapshot, resend incrementally from a known-good common snapshot, and preserve evidence if corruption is on disk.

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

A Veeam checksum mismatch means blocks read back during restore do not match the hashes stored when the backup was written. Treat it as storage or in-flight corruption until proven otherwise. Check the repository disks and transport path, run a health check on the whole chain, restore from an earlier point if needed, and take an active full backup to build a clean chain.

veeam restore failed checksum mismatch

Use this when

• A Veeam restore or file copy stops with checksum mismatch.
• Veeam health check flags a backup file as corrupted.
• Only one restore point fails while neighbours restore cleanly, or several fail on one repository.

Not for this skill when

• restic or Borg reports checksum problems. Those formats need their own repair flow.
• The backup job fails before writing anything. That is a job failure, not corruption.

Steps

1. Note the exact backup file, restore point, and block range in the error and stop repeated restore attempts against it. Verify: the affected file and point are recorded
2. Check repository storage health: array or disk events, filesystem errors, and recent power or connectivity incidents on the repository server. Verify: storage health is confirmed or a fault is found
3. Run the Veeam health check on the job to map how far the corruption extends across the chain. Verify: you know which points are affected and which are clean
4. Restore the data from the newest clean point, accepting the older recovery point if the newest is damaged. Verify: the restore completes and spot-checked files open
5. Take an active full backup to start a clean chain, then run a health check on it. Verify: the new chain passes the health check with no mismatch

Variant phrasings

veeam backup file corrupted checksum

The corruption-worded variant of the same fault.

veeam health check failed corrupted

The health-check phrasing.

veeam vbk checksum mismatch

The file-extension phrasing for VBK chains.

Compatibility: Veeam Backup and Replication 11 and 12 with VBK, VIB and VRB chains on Windows or Linux repositories, including hardened and scale-out repositories.

Why it happens

Veeam stores per-block hashes in backup metadata. Corruption creeps in through failing disks, faulty memory or controllers on the repository, interrupted writes during power loss, or network errors on the path to network repositories. The mismatch is detected only on read, which is why it often appears first during a restore or health check.

Edge cases / pitfalls

• A single bad point with healthy neighbours points to a transient write error. Widespread mismatch points to storage failure.
• Do not run repository filesystem repair tools against a mounted Veeam repository without a support-guided plan.
• Copy a second replica to different storage before discarding the damaged chain if it holds the only copy of older data.

Provenance

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

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

Thread query: veeam restore failed checksum mismatch

TL;DR: A Veeam checksum mismatch means blocks read back during restore do not match the hashes stored when the backup was written. Treat it as storage or in-flight corruption until proven otherwise. Check the repository disks and transport path, run a health check on the whole chain, restore from an earlier point if needed, and take an active full backup to build a clean chain.