01 · THE RULE

Three copies, two media, one off site — and two extra digits.

The classic rule is a memory aid for surviving correlated failures. The modern extension exists because ransomware made two of the original assumptions optimistic.

  • 3 copies of the data — the live one plus two backups.
  • 2 different media or devices, so a single controller, drive model or enclosure cannot take out everything.
  • 1 copy off site, because fire, theft and flood do not respect a shelf.
  • 1 copy offline or immutable — disconnected, append-only or write-protected. This is the anti-ransomware digit.
  • 0 errors on restore, verified by an actual test rather than a green tick in a status window.

Synchronisation is not backup. A cloud sync folder faithfully propagates deletion and encryption to every device within seconds. It is excellent availability and it is not a backup, unless you are deliberately using its version history — and you have checked how far back that history goes.

02 · SCOPE

Back up what you cannot recreate. Skip the rest.

Backing up everything is how backups become slow, expensive and eventually abandoned. Sort your data by whether the internet can replace it.

CategoryExamplesPriority
IrreplaceablePhotos, video, documents, scans, letters, financial records, creative project filesEvery copy, every rule, no exceptions
Expensive to rebuildConfiguration, dotfiles, password vault export, licence keys, signing keys, VM imagesBack up. Small, and a nightmare to reconstruct.
Reproducible with effortCode with a remote, edited exports, downloaded datasetsLocal copy is usually enough
Freely replaceableInstallers, games, cached media, node_modules and build outputExclude. This is what makes backups too big to run.

The items people forget until it is too late

  • Password manager recovery material — the emergency kit or export, stored somewhere that does not require the password manager to reach.
  • Two-factor recovery codes — printed. If they live only on the phone you lost, the backup does not help you.
  • Android and iOS keystores or signing certificates — losing an app signing key means you cannot update your own published app.
  • Browser profile bookmarks and extension configuration — small, and irritating to rebuild.
  • The list of installed software — a package manager export takes seconds and saves an entire afternoon.

03 · THREAT MODEL

A backup that only survives dead hardware is half a backup.

MODE—01 Hardware failure

A drive dies. Any second copy solves this, which is why it is the only case most setups actually cover.

MODE—02 Human error

You delete or overwrite something and notice three weeks later. Only versioned backups with enough retention survive this.

MODE—03 Malicious encryption

Ransomware encrypts everything reachable, including the always-connected external drive and mapped network shares. Only offline or immutable copies survive.

MODE—04 Location loss

Fire, flood, theft. Only the off-site copy survives, which is the digit people skip because it feels unlikely right up until it is not.

Check your current setup against all four. An external drive that stays plugged in covers exactly one of them. That is the most common backup arrangement in the world, and it is the one ransomware was designed to defeat.

04 · THE BUILD

One local target, one off site, both versioned.

This is a specific arrangement rather than a survey. Substitute tools freely — the shape is what matters.

Layer 1 — versioned local backup

  • An external drive that is not always connected. Plug it in for the run, unplug it afterwards. That single habit converts the drive from a ransomware target into an offline copy.
  • A deduplicating, versioned backup tool such as Restic, Kopia, Duplicati or a vendor agent. Deduplication is what makes daily snapshots affordable; versioning is what saves you from mode 02.
  • Keep a sensible retention window: daily for a fortnight, weekly for a couple of months, monthly for a year. Cheap, and it covers the mistake you have not noticed yet.
EXAMPLE · RESTIC, LOCAL REPOSITORY
# Once: create an encrypted repository on the external drive
restic init --repo E:\backups\home

# Each run: snapshot the folders that matter, skipping the noise
restic -r E:\backups\home backup C:\Users\you\Documents --exclude "**/node_modules"
restic -r E:\backups\home backup C:\Users\you\Pictures   --exclude "**/*.tmp"

# Prune to a retention policy
restic -r E:\backups\home forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

# Verify the repository can actually be read back
restic -r E:\backups\home check --read-data-subset=5%

Layer 2 — encrypted off site

  • Cloud object storage with the same backup tool, so the data is encrypted before it leaves the machine. This is the practical way to get an off-site copy without trusting the provider with plaintext.
  • Or a drive at another address — a relative’s house, an office drawer. Rotate it monthly. Unglamorous, free, and it works.
  • Enable object lock or immutability if the provider offers it. This is what makes the off-site copy resistant to an attacker who has your credentials.

Layer 3 — the boring habits

  • Automate the local run with a scheduled task, and make failures visible. A silent backup that stopped three months ago is worse than none, because you stopped worrying.
  • Export your installed-software list during the same run.
  • Keep one full system image if reinstalling Windows and its applications would cost you a working day.

05 · KEYS

Encrypt the copies. Then solve the key problem.

Any backup that leaves your home should be encrypted before it goes. That immediately creates a second problem: a key you cannot lose and cannot leave lying next to the data.

  • Encrypt client side. Tools like Restic and Kopia encrypt before upload, so the storage provider holds ciphertext. Provider-side encryption protects against the wrong threat.
  • Use a long passphrase, stored in your password manager, and make sure the password manager itself is recoverable without the backup.
  • Write the recovery material down. On paper, somewhere physical. A repository key that exists only inside the encrypted vault it protects is a circular dependency you will discover at the worst moment.
  • Encrypt the external drive too — BitLocker on Windows, or the backup tool’s own encryption. A stolen backup drive is a data breach with your name on it.
  • Test the passphrase from a different machine, at least once, before you rely on it.

The most common total loss is not a dead drive. It is an encrypted backup whose passphrase was only in the head of someone who was sure they would remember it. Write it down.

06 · THE TEST

A backup you have never restored is a hypothesis.

Restore testing is the step everyone skips, and it is the only step that proves any of the others worked.

Quarterly, in fifteen minutes

  • Pick a random file from six months ago and restore it to a new location. Open it. Confirm it is intact and is the version you expected.
  • Restore a whole folder and compare file counts and sizes against the source.
  • Do it from the off-site copy at least once a year, not just the convenient local one.
  • Time it. “How long until I am working again” is the number that determines whether your plan is adequate, and most people have never measured it.

Yearly, in an hour

  • Restore to a different machine, or a virtual machine, using only what you have written down. No help from the running system.
  • Verify the encryption passphrase works from that clean environment.
  • Check that the tool itself is still available and still supports your repository format.
  • Re-read your own notes and fix whatever you have to remember rather than read.

If you do exactly one thing after reading this: restore a single file from your existing backup right now. A surprising share of people discover at that moment that they do not have one.

07 · QUICK ANSWERS

Backups, briefly.

What does the 3-2-1 backup rule mean?

Three copies of your data, on two different media or devices, with one copy off site. The modern extension adds one copy that is offline or immutable, so ransomware cannot reach it, and zero errors on restore, meaning you have actually tested that the backup can be read back.

Is cloud sync the same as a backup?

No. Synchronisation propagates changes, including deletions and ransomware encryption, to every connected device within seconds. It provides availability, not recovery. It only counts as a backup to the extent you use its version history, and you should check how far back that history reaches before relying on it.

How often should I back up?

Match the interval to how much work you are willing to redo. Daily automated backups suit most people, with an off-site copy updated weekly. What matters more than frequency is that the job is automated, that failures are visible, and that retention is long enough to recover a mistake you notice weeks later.

Will my backup survive ransomware?

Only if at least one copy is offline or immutable. Ransomware encrypts everything it can reach, including permanently connected external drives and mapped network shares. Unplug the backup drive between runs, or use storage with object lock, and keep versioned snapshots so you can roll back to a point before the infection.

How do I test a backup?

Restore a real file from several months ago to a new location and open it. Once a year, restore to a different machine using only your written notes, verify the encryption passphrase works there, and time how long a full recovery takes. That number, not the backup software status page, tells you whether your plan is adequate.