File backup tools
Verify files with checksums
Generate and check cryptographic hashes to detect unexpected changes during storage or transfer.
10 minute lesson
A checksum fingerprints file bytes. Run a file through SHA-256 and you get a short hex string. Change one byte anywhere in the file, and the string comes out completely different. That property lets you detect corruption during storage or transfer — but only if you saved the expected hash beforehand. It detects change when the expected hash is protected and compared later.
This matters for backups because storage lies quietly. Disks develop bad sectors, transfers get interrupted, and a backup archive can rot for two years before you try to open it.
Create and verify a manifest
Generate the hash right after creating the archive, while you know it’s good:
shasum -a 256 notes.tar.gz > notes.tar.gz.sha256
shasum -a 256 -c notes.tar.gz.sha256
The first command writes a manifest file containing the hash and the filename. The second reads that manifest and re-hashes the file. Success looks like this:
notes.tar.gz: OK
On Linux, sha256sum works identically. Run the -c check after every copy of the archive to a new destination, and again periodically on cold storage.
Prove the check works
Never trust a verification you’ve never seen fail. Change one byte in a disposable copy and confirm verification fails:
cp notes.tar.gz broken.tar.gz
printf 'x' | dd of=broken.tar.gz bs=1 seek=100 conv=notrunc
shasum -a 256 -c notes.tar.gz.sha256
# after renaming broken over the original:
# notes.tar.gz: FAILED
# shasum: WARNING: 1 computed checksum did NOT match
The non-zero exit status means you can script this and alert on failure.
Limits worth knowing
Store the expected manifest separately when tampering is in scope. An attacker who can modify the archive can regenerate the .sha256 file sitting next to it in the same directory.
Timing matters too: a checksum taken from an already-corrupted file just fingerprints the corruption. Hash at creation time, not later.
And a checksum does not create another copy and does not tell you which version is correct by itself. It tells you that bytes changed, never which side is right. Detection, not recovery.
Lesson completed