The 3-2-1 backup rule: how to put it into practice as an SMB

Everyone talks about backups; hardly anyone tests them. Here's how to implement the 3-2-1 rule without turning it into an IT project — including a check you can do today.

When we visit a new client and ask "how are your backups looking?", we usually get one of three answers: "our supplier handles that", "it's in the cloud, so it's sorted" or an uncomfortable silence. None of those three is a backup strategy.

The 3-2-1 rule has been around for decades and still holds up perfectly. It's simple enough to explain over lunch and concrete enough to start on tomorrow. In this post we explain what it means, how to apply it without an IT department, and which step almost everyone skips.

What does the 3-2-1 rule say?

Three numbers, three commitments:

• 3 copies of your important data. The original counts, so that means the original plus two backups.
• 2 different media or storage types. Not everything on the same drive or with the same provider.
• 1 copy off-site. Physically or logically in a different location from the original.

The reasoning: one failure, one mistake, or one targeted attack should never be able to hit all copies at the same time. Fire in the office? Your off-site copy saves you. Ransomware on the file server? Your other medium saves you. Provider goes bust? Your second copy elsewhere saves you.

What about "it's in the cloud, isn't it"?

Microsoft 365, Google Workspace and most accounting packages offer excellent uptime. But uptime is not a backup. If an employee accidentally empties a SharePoint library, if ransomware encrypts files through a shared folder, or if an account is hacked and mail folders are deleted — that damage happily syncs straight back to "the cloud".

Microsoft states in its own terms of service that customers are responsible for their own data. The recycle bin and version history are useful, but they are no substitute for a proper backup with weeks or months of retention.

The 3-2-1 rule in practice: four scenarios

1. Microsoft 365 or Google Workspace

The original lives in the cloud. For your second and third copy, choose a dedicated backup service (think providers such as Afi, Synology Active Backup, Veeam or Keepit). These pull your mail, OneDrive, SharePoint and Teams data daily and store it on their own infrastructure — giving you a different medium and an off-site copy in one go.

2. Accounting

Most accounting packages offer an export function. Schedule a monthly export of your administration (XML or Audit File) to a separate location. If in doubt, ask your accountant whether they can keep a copy in their own archive. Two birds, one stone.

3. Your website

This is where we see things go wrong most often. The hosting provider has "backups", but they sit on the same server, are only kept for 14 days, or can only be restored by the host at an hourly rate. Make sure you have your own copy alongside the host's backup — for example via a plugin that writes weekly to external storage (S3, Backblaze, your own NAS).

4. Local files and NAS

If you still have files stored locally or on a NAS: copy to the cloud (off-site) and optionally a second external drive that you disconnect in the evening. A drive that is always connected is not a backup — it will be encrypted right along with everything else in a ransomware attack.

The step everyone skips: a restore test

A backup that has never been restored is just an assumption. We have seen a client faithfully back up a database for three years, only for the export script to skip the table containing customer data. For three years. They only found out when they actually needed to restore it.

Schedule a mini restore test at least once a quarter:

• Restore one file from your M365 backup. Does it work? Is the content correct?
• Restore your website backup to a staging environment. Does it come up?
• Open your latest accounting export. Is everything in there?

Write down the outcome. Date, who did it, whether it succeeded. Two pages of notes a year is enough to demonstrate at an audit or incident that you are genuinely keeping on top of it.

What should you document?

For every system in your SMB you want to know:

1. What is being backed up (which folders, which mailboxes, which databases)?
2. How often (daily, weekly)?
3. How long is it retained (retention period)?
4. Where is the backup stored (provider, location)?
5. Who can restore it and how?
6. When was it last tested?

A simple table in a shared document is sufficient. More important than the format is that it exists and that someone is responsible for it.

Start small, start today

You don't need to sort everything at once. Start with the two systems your business depends on most — usually your email environment and your website. Then build from there. A half-implemented 3-2-1 on your most critical systems is infinitely better than a perfect plan gathering dust in a drawer.

Want help setting up or testing your website backups? Take a look at our website backup and restore service, or let us carry out a general website security check. Prefer to run your own quick check first and see whether your site is even responding promptly? Start with our speed test — a slow site you can't restore is doubly painful.