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.

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.