File backup tools

Verify files with checksums

Generate and check cryptographic hashes to detect unexpected changes during storage or transfer.

A checksum is a fingerprint of a file’s 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, and kept it safe. A checksum detects change when you compare it against a protected copy later.

This matters for backups because storage lies quietly. Disks develop bad sectors. Transfers get interrupted. 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 with the hash and the filename. The second reads that manifest and hashes the file again. Success looks like this:

notes.tar.gz: OK

On Linux, sha256sum works the same way. 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 the check catches it:

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 check exits with a non-zero status. That means you can script it and alert on failure.

Limits worth knowing

Store the manifest somewhere else when tampering is in scope. An attacker who can modify the archive can also regenerate the .sha256 file sitting next to it.

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. It tells you that bytes changed, never which side is right. Detection, not recovery. You still need the second copy from the 3-2-1 lesson.

Lesson completed