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

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →