Every hosting provider says they do backups. Almost none of their customers could say, right now, how much data they would lose if the site vanished tonight. The 3-2-1 rule is the simplest framework for closing that gap — and it is worth understanding even if someone else runs your infrastructure.
The rule in one sentence
Keep three copies of your data, on two different systems, with one of them somewhere else entirely. That is the whole rule, and each number exists because of a specific way businesses have lost everything:
- Three copies, because any single backup can be corrupt, incomplete, or mid-write at the wrong moment. One backup is a coin flip.
- Two different systems, because whatever destroys the original — a failed disk, a bad update, ransomware — should not be able to destroy the copy in the same motion.
- One offsite, because some failures take out a whole provider region or account. If every copy shares a login, a data center, or a billing relationship, they share a fate.
The live site itself counts as copy number one. So in practice the rule asks for two real backups, kept apart from each other — less daunting than it first sounds.
What actually counts as a copy
This is where most backup strategies quietly fail. Several things feel like backups and are not:
- RAID or “redundant storage” is not a backup. It protects against a disk dying, not against deleting the wrong table. Redundancy faithfully replicates your mistakes.
- A sync service is not a backup. Sync’s whole job is to copy changes everywhere — including the change where the files got encrypted or erased.
- A copy on the same server is barely a backup. It survives an application bug but not the server itself.
A real copy is independent — a failure of the original cannot reach it — and versioned, so you can go back to before the problem, not just to the most recent snapshot of the problem. For a website that means yesterday’s copy and last week’s copy both exist, and the credentials that manage the backups are not the same ones an attacker would get by compromising the site.
Restores are the metric; backups are just the method
Nobody actually wants backups. They want restores — the moment a broken site becomes a working one again. Yet almost all backup effort goes into the copying, and almost none into proving the way back works.
A backup that has never been restored is a hope, not a plan. Archives turn out corrupt, database dumps turn out partial, the one person who knew the procedure turns out to be on leave. None of that is discoverable on the day you need it — only on the day you rehearse it.
The only backup question that matters: when did someone last restore one, and how long did it take?
Put a restore drill on the calendar the way you would a fire drill — quarterly is plenty for most businesses. Restore to a staging copy, click around, time it, write the time down. That number transforms your continuity plan from adjectives into arithmetic.
RPO and RTO, in plain words
Two pieces of jargon are worth learning because they turn a vague worry into two concrete numbers.
- RPO — recovery point objective — is how much recent work you can afford to lose. Daily backups mean up to 24 hours of orders, edits, and signups can vanish. For a brochure site that is nothing; for a busy store it may be unacceptable.
- RTO — recovery time objective — is how long you can afford to be down while the restore happens. This is the number your restore drills measure.
Decide both numbers as a business decision, not a technical one: what does an hour of downtime cost, and what does a day of lost data cost? Then check the arithmetic. If your RPO is one hour and your backups run nightly, the strategy contradicts the requirement — better to discover that in a meeting than in an outage.
Applying 3-2-1 to a typical business site
A working setup for a business website is refreshingly ordinary. Your site has three things worth protecting: the files (code, themes, uploads), the database (orders, content, users), and the configuration (server settings, DNS records, credentials — the stuff everyone forgets until rebuild day).
- Copy one is the live site.
- Copy two is your host’s automated daily backup — files and database together, versioned, restorable on request or by button.
- Copy three is a periodic export you keep somewhere your host cannot touch: a weekly download of the database and files into your own cloud storage account.
The split of responsibility matters. Your host should provide the automated backups, the versioning, the offsite-from-your-server storage, and — critically — a practiced restore path. You own copy three, the documented restore steps, and an export of your DNS records and credentials. That way, even the worst case — losing the provider relationship itself — is a bad month, not the end of the business.
3-2-1 is not about paranoia; it is about making sure no single mistake, machine, or company can erase your business’s work. Two independent copies, one of them yours alone, and a restore you have actually rehearsed — that is the whole discipline, and it fits on an index card.
Every Qubits hosting plan includes daily backups, and we treat restore testing as routine rather than heroics — because a backup nobody has restored is a rumor. If you are not sure what your current provider would actually recover for you, ask us and we will help you find out before it matters.