rsync --checksum vs a Manifest: Do Your Files Really Match?

• →Default rsync trusts size + mtime — fast, but it can miss corruption.
• →-c reads every byte and compares checksums (MD5).
• →-avc --dry-run lists what differs without touching anything.
• →A manifest adds a dated SHA-256 baseline you can re-verify later.

rsync's default trap

rsync's speed comes from a shortcut: for each file, it compares the size and modification time on both sides. If they match, rsync assumes the file is identical and skips it. That assumption is right almost always — and wrong exactly when it matters most. A file that was corrupted in place (a bad sector, a half-finished write, a tampered byte) can keep the same size and mtime, and rsync will happily leave the bad copy alone.

For everyday mirroring that's a fine trade. For "I need to be sure this copy is correct," the default isn't a verification — it's an optimistic guess.

What --checksum changes

Adding -c / --checksum tells rsync to stop trusting metadata and compute a checksum of every file on both sides, comparing those instead:

# force a full content comparison (slower, but honest)
rsync -avc /data/source/ /backup/dest/

Now corruption is caught regardless of size and timestamp. The cost is speed: rsync has to read every byte on both ends. Modern rsync uses MD5 for this checksum — fine for catching accidental corruption, but worth knowing if your threat model includes deliberate tampering (where MD5 is the wrong choice).

Compare two trees without copying

One genuinely useful pattern: use checksum mode plus --dry-run as a read-only "do these two folders actually match?" check. rsync lists the files that differ and transfers nothing:

rsync -avc --dry-run /data/source/ /backup/dest/

sending incremental file list
reports/q3.xlsx
config/app.yml

# empty list = the trees match; any names = files that differ

It's a quick, dependency-free way to confirm a copy landed correctly — as long as you still have both trees on hand to compare.

Where rsync stops short of verification

rsync is a synchronization tool, and that shapes what it can and can't tell you:

The pattern rsync can't express is "prove this folder is exactly as I left it" — because it always needs a second tree to compare against, and it produces no durable record of the check.

When to reach for a manifest

A manifest flips the model: instead of comparing two live trees, you capture a SHA-256 fingerprint of one tree once, then check reality against that fixed baseline whenever you want. The FolderManifest CLI does this on Linux and Windows:

# fingerprint the source when it's known-good
foldermanifest generate /data/source --format json --out source-baseline

# later — verify the backup against that baseline (no source tree needed)
foldermanifest verify /backup/dest --manifest source-baseline.json
echo "exit: $?"   # 0 = matches, 1 = added/removed/modified

Because it compares against a stored snapshot, it catches additions and deletions, uses SHA-256, and leaves a dated report — none of which a transfer tool is built to do. The exit code drops into cron or CI directly.

Use both — they're complementary

This isn't rsync versus FolderManifest; it's copy versus prove. Let rsync move the bytes, then let a manifest certify them:

rsync -a /data/source/ /backup/dest/                       # move the data
foldermanifest verify /backup/dest --manifest source-baseline.json  # prove it landed intact

rsync gets the files there efficiently; the manifest gives you a SHA-256, audit-ready answer to "did it land intact, and has it stayed that way?" To run that check on a schedule, see automating folder verification, and for the basics of sha256sum on Linux.