The 3-2-1 backup rule for business data explained

What the 3-2-1 backup rule means

The 3-2-1 rule is the simplest reliable standard for protecting business data against hardware failure, ransomware, accidental deletion and site disasters. It states that you should always keep:

• 3 copies of every important dataset (the live copy plus two backups).
• 2 different types of storage media, so a single technology fault cannot destroy every copy.
• 1 copy offsite, physically separated from your office or primary server.

The logic is probability. If each copy has an independent chance of being lost, three copies on two media in two locations make simultaneous failure extremely unlikely.

Why one backup is not enough

A single backup on a NAS in the same room fails the moment there is a fire, theft, flood, power surge or ransomware that reaches the network share. Most real data loss is not a lone disk dying, it is a correlated event that hits the original and the backup together. The 3-2-1 rule exists specifically to break that correlation.

Applying the rule step by step

Copy 1: the production data

This is your live server, workstation or database. It does not count as a backup, no matter how redundant the RAID array is. RAID protects against a failed disk, not against deletion, corruption or encryption.

Copy 2: a local backup

Keep a second copy on separate hardware in your own network for fast restores. A NAS, a dedicated backup server or an external disk all qualify. Automate it so it runs without anyone remembering. A typical nightly pull with restic:

restic -r /mnt/backup/repo backup /var/www /etc /home
restic -r /mnt/backup/repo forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Copy 3: the offsite copy

Send one copy out of the building, to a second data centre, object storage or a rotated encrypted disk kept elsewhere. Encrypt before it leaves your control. Example offsite sync to a remote server over SSH:

restic -r sftp:backup@offsite.example.net:/srv/repo backup /var/www
# or with rsync for plain file mirrors
rsync -avz --delete /var/www/ backup@offsite:/srv/mirror/www/

The two media requirement in practice

"Two media" today rarely means tape plus disk. It usually means two independent failure domains: for example one copy on local SSD and one in remote object storage, or a NAS plus a cloud backup account. The point is that the same firmware bug, the same controller, or the same ransomware credential cannot reach both.

Extending to 3-2-1-1-0

Modern practice adds two digits:

• 1 copy offline or immutable (air-gapped disk, or object storage with an immutability lock) so ransomware cannot overwrite it.
• 0 restore errors, meaning every backup is tested and verified, not just assumed.

Test your restores, always

A backup you have never restored is only a hope. Schedule real restore drills at least quarterly. Verify integrity automatically after each run:

restic -r /mnt/backup/repo check --read-data-subset 10%
restic -r /mnt/backup/repo restore latest --target /tmp/restore-test

Then confirm the restored files open, the database imports, and the application starts.

Retention and the 3-2-1 rule

Keep enough history that you can go back past a problem you did not notice immediately. A silent corruption or a slow ransomware encryption may only surface after days. A grandfather-father-son schedule (daily for a week, weekly for a month, monthly for a year) is a sensible default and satisfies most GDPR and NIS2 recovery expectations.

Practical takeaway

Write down where your three copies live, which two media they use, and which one is offsite. Automate all three, encrypt anything that leaves the building, keep one copy immutable, and test a real restore this quarter. If you cannot name those things right now, you do not yet have a backup, you have a single point of failure.