3-2-1 backups: the verified copy strategy with SHA-256

Everyone has backups until they need them. The profession's uncomfortable truth: most copy systems fail exactly on the critical day — because a restore was never tested, because the destination had been silently corrupt for months, or because ransomware encrypted the connected copies too. This article builds a backup system that survives those traps, cryptographic verification included.

The 3-2-1 rule (and its evolution)

The classic standard remains the right starting point:

• 3 copies of the data: the original + two backups.
• 2 different media: for example local disk + cloud storage. One medium = one failure mode.
• 1 off-site copy: if fire, theft or ransomware hits the local site, the external one survives.

The modern version adds a fourth letter: 3-2-1-1-0, where the extras mean:

• 1 immutable/offline copy: storage that cannot be modified or deleted for a period (S3 Object Lock, immutable snapshots). It's the only real defense against ransomware actively hunting network shares to encrypt backups too.
• 0 verified errors: zero unverified copies. An unchecked backup is hope, not backup.

What to copy: the hierarchy almost everyone skips

Not everything deserves the same policy. Order your data by criticality and change rate:

• Irreplaceable data (databases, source code, own documents): daily frequency, long retention.
• Rebuildable with effort (configurations, environments): git versioning usually suffices; weekly copy.
• Regenerable (node_modules, builds, caches): never copied — exclude them explicitly.

For databases, the critical nuance: copying the data file while hot produces corrupt backups. Use logical dumps (pg_dump, mysqldump) or consistent volume snapshots. In Docker, remember the volume is not a backup — you must dump it.

Minimum viable automation

A nightly cron with rsync covers 80% of personal cases:

#!/bin/bash
set -euo pipefail

DEST="/mnt/backup/$(date +%Y-%m-%d)"
SRC="/srv/data"

rsync -a --delete --link-dest="/mnt/backup/latest" "$SRC/" "$DEST/"
ln -sfn "$DEST" /mnt/backup/latest

# Batch integrity verification
find "$DEST" -type f -exec sha256sum {} + > "$DEST.sha256"

# Rotation: delete batches older than 30 days
find /mnt/backup -maxdepth 1 -mtime +30 -exec rm -rf {} +

--link-dest creates incremental backups sized like differentials but behaving like full ones (hard links to unchanged files). And the key line is the sha256sum one: it generates each copy's hash manifest — the foundation of verification coming next.

Integrity verification: why bits rot

Copies degrade silently: bad sectors, non-ECC RAM with real cosmic-ray errors, problematic SATA cables, cloud sync bugs. The phenomenon has a name — bit rot — and its danger is silence: the file opens... until it reaches the damaged zone.

Defense is mathematical: the SHA-256 hash of every file computed at backup time acts as a fingerprint. Any later alteration —a single bit— changes the hash completely (avalanche effect). Periodic verification compares:

cd /mnt/backup/2026-08-15
sha256sum -c 2026-08-15.sha256 --quiet && echo "OK" || echo "CORRUPTION DETECTED"

Automated monthly over rotating samples (or everything, if volume allows), silent corruption becomes early warning. For verifying loose files —a critical download, an important document— our hash checker computes SHA-256 in the browser without uploading the file anywhere.

The restore test: the part everyone skips

An untested restore is theory. Full test, quarterly at minimum:

1. Restore a random set of files to a temporary location.
2. Compare hashes against the manifest.
3. Open representative documents; boot the restored database and run queries.
4. Time the process: your real RTO (recovery time objective) is that number, not the plan's.

Write down results. If restoring 500 GB takes 6 hours and your business tolerates 2, you have a finding, not a backup.

Retention and encryption

Two final design decisions:

Tiered retention beats uniform long retention: dailies for 7 days, weeklies for 4 weeks, monthlies for 12, yearly per regulation. Covers recent accidental deletion (yesterday), slow corruption (months back) and legal obligations.

Encryption whenever data leaves your hardware: restic and borg encrypt natively before sending; in cloud, enable client-side encryption on top of provider's — the copy an attacker steals from the bucket shouldn't be readable. And protect access: backup credentials separate from the main system's, or admin-access ransomware deletes both worlds.

FAQ

Does RAID count as backup? No. RAID protects against disk failure, not accidental deletion, logical corruption, ransomware or fire. It's redundancy, something else entirely.

How often should I verify hashes? Monthly over small collections; on large ones, rotating sampling covering 100% per quarter. After any disk incident, immediate full verification.

Automatic cloud services? Valid and convenient under two conditions: client-side encryption (key never reaches the provider) and demonstrated exportability — practice recovering your data without their official app before truly needing it.

Verify any file's integrity with our hash calculator, free and right in your browser.