rsync --checksum vs. Post-Restore Hash Manifests for SSH Data Recovery

For multi-terabyte restores with a strict provenance requirement, the manifest-based approach is the more sustainable architecture — but only if your backup pipeline already generates and protects the hashes. If no manifest exists from the backup phase, rsync --checksum is the correct fallback, because retrofitting verification after the fact is impossible without a trusted reference.

The core distinction

The two patterns answer different questions. rsync --checksum answers: "does the destination match what is on the source right now?" A hash manifest answers: "does the restored data match what was captured at backup time?" For provenance — proving the restored bytes are the bytes you originally archived — only the manifest provides that chain. rsync's inline comparison trusts the current state of the source, which may itself have drifted or been corrupted since the backup was taken.

Why the I/O penalty matters at scale

With --checksum, rsync reads every file fully on both sides to decide what to transfer, then the receiving side reads again during the transfer itself. On a multi-terabyte dataset this roughly doubles read load on the backup server and can turn the restore into the dominant I/O event on that host. The default quick-check (size plus mtime) avoids this but can miss silent corruption — a bit-flipped block with preserved size and timestamp passes unnoticed.

A tar-over-SSH stream, by contrast, is essentially sequential read on the source and sequential write on the destination. Verification then happens once, locally, against the manifest:

ssh backuphost 'tar -C /data -cf - .' | tar -C /restore -xf -
sha256sum -c /manifests/backup-2026-10.sha256 \
  | grep -v ': OK$'

The local re-hash is a single sequential pass over the restored data — cheap compared to rsync's double-sided reads, and it can run while other restores proceed.

Where each approach fails

• Manifest approach: worthless if hashes weren't generated during backup, if the manifest itself wasn't integrity-protected (store it separately, ideally signed or on a different host), or if file paths changed between backup and restore.
• rsync --checksum: can time out or saturate the backup server's I/O on very large trees, and checksum algorithm differences across rsync versions (MD5 vs. MD4 vs. xxhash in newer releases) can cause renegotiation overhead or unexpected behavior when source and destination versions differ.
• Both: neither protects against corruption introduced after verification — a failing destination disk invalidates either result. Verify, then scrub.

Recommendation

1. If you control the backup pipeline: generate a SHA-256 manifest at backup time, store it separately from the data, and verify restores against it. This scales to multi-terabyte datasets because hashing is a single streaming pass and verification is decoupled from the backup server.
2. If no manifest exists and you must restore now: use rsync --checksum, but throttle it (--bwlimit, ionice) and run it during off-peak hours on the backup host.
3. Whichever you choose, run a spot verification on a representative subset first and measure wall time and source-side I/O (iostat -x 5) before committing to the full restore.

Uncertainty and assumptions

This assumes a Linux-like environment with GNU coreutils and rsync 3.x on both ends; exact checksum negotiation behavior varies by version, so confirm with rsync --version on both hosts. The claim that manifest verification "scales better" is an architectural argument about I/O patterns, not a measured benchmark — if your backup server has abundant I/O headroom and your restore target is the bottleneck, the practical difference may be small. One detail that would change the recommendation: whether the backup phase already produces hashes. If it does, the decision is effectively made.