> (Side note, doesn't 'zfs send' blindly trust TCP checksums?)

No.

https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Data...

> End-to-end checksums are a key feature of ZFS and an important differentiator for ZFS over other RAID implementations and filesystems. Advantages of end-to-end checksums include:

> [...]

> - checksums on ZFS replication streams, zfs send and zfs receive, ensure the data received is not corrupted by intervening storage or transport mechanisms

Edit: Also, as Asmod4n points out in a sibling comment, neither zfs send nor zfs recv actually transmit or receive any data. They just generate a data stream that you are then responsible for handling somehow (piping to e.g. ssh, redirection to a file, etc).

> Streams are checksummed, so corruption introduced by the network or by intermediate storage is detected on receive.

https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Oper...

I've set up all NFS mounts within my home LAN over WireGuard partly for this exact reason. The impacts to bandwidth and latency are negligible, and even the increase in CPU usage remains relatively low (at least on non-ancient hardware). This reduces some of my worries about silent data corruption (at least from this potential source).

zfs send/recv doesn’t do networking on its own?