How to Back Up Your Website Properly: The 3-2-1 Rule

What is the 3-2-1 backup rule for websites?

The 3-2-1 rule is a simple discipline for surviving data loss: keep 3 copies of your website, store them on 2 different types of media or storage, and keep 1 copy offsite — physically and logically separate from your live server. Your production site counts as the first copy, so in practice you need two more backups, one of them somewhere your main host cannot touch.

It started as an enterprise data-protection guideline, but it maps cleanly onto running a website in 2026. Most catastrophic losses are not exotic — a botched plugin update, a hacked admin account, a billing lapse that suspends your hosting, or a data-center incident. The 3-2-1 structure is designed so that no single failure, mistake, or attacker can wipe out every copy at once. That redundancy is the whole point.

A backup is not the file you saved. It is the restore you successfully completed. Until you have restored it, you only have hope stored on a disk.

The sections below break the rule into the parts that actually matter: what to back up, how often, where the offsite copy should live, and how to verify the whole thing works before you need it at 3 a.m.

Why three copies on two media types?

The numbers in 3-2-1 are not arbitrary — each one closes a specific failure mode that catches site owners off guard.

Three copies survive correlated failures

If you keep only one backup next to your live site, a single event — a compromised server, a ransomware encryption pass, an accidental delete — can take both at once. A third, independent copy means an attacker or accident has to find and destroy three things in three places, which is dramatically less likely.

Two media types defeat shared weaknesses

'Two media' originally meant tape and disk. In 2026 it usually means two storage technologies or providers that fail independently: your host's block storage plus a separate object-storage bucket, or local NVMe plus a cloud archive. The goal is that whatever kills one copy — a firmware bug, a provider outage, a corrupted filesystem — does not also kill the other.

What most hosts will not tell you: their 'daily backups' often live on the same infrastructure as your site, sometimes the same physical array. That is convenient for restoring a fat-fingered file, but it is copy two and three collapsed into one — and it disappears the moment your account is suspended or the provider has a bad day. The offsite copy is the one that saves you, and it is the one most people skip.

What exactly should you back up — files or database?

Both, together, and in sync. A modern site is two moving parts: the files (code, themes, plugins, uploaded images and media) and the database (posts, pages, users, settings, comments, orders). Restore one without the other and you get a site that looks present but is broken — images with no records, or content with no templates.

A complete website backup should capture:

• Application files — your CMS core, themes, plugins, and any custom code.
• User uploads and media — often the largest and least replaceable part; photos and documents rarely live anywhere else.
• The full database — exported as SQL, taken at a moment consistent with the files.
• Server and config details — web-server rules, redirects, cron jobs, and environment variables you would otherwise rebuild from memory.
• DNS and domain records — export your zone file; recreating dozens of records by hand during an outage is brutal.

The synchronization point is the trap. If your files are backed up at midnight but the database dump runs at 2 a.m., an order placed in between exists in one copy and not the other. For busy or transactional sites, put the site in maintenance mode during the backup, or use a host that takes a consistent point-in-time snapshot of the whole environment at once.

How often should you back up, and how many versions to keep?

Match your backup frequency to how much work you are willing to lose — your recovery point objective. A blog updated weekly is fine with daily backups; a store taking orders every few minutes needs near-continuous protection. The honest test is to ask: if the site reverted to my last backup right now, how much would I have to redo?

Keeping multiple versions matters more than people expect, because of a quiet threat: silent corruption and delayed-discovery hacks. Malware or a database problem can sit unnoticed for weeks. If you only keep yesterday's backup, every copy you own may already contain the infection. A ladder of versions — daily for a month, weekly for a quarter, monthly for a year — lets you roll back to a known-clean point. Ransomware actively targets backups, so versioned, offsite copies that the live server cannot overwrite are your real defense.

Where should your offsite backup live?

The '1' in 3-2-1 — the offsite copy — does the heaviest lifting, so choose its home deliberately. The core requirement is independence: it must survive events that take down your main host, including the boring catastrophe of your hosting account being suspended over a billing dispute or a content complaint. If your offsite backup is just another folder on the same provider, it is not really offsite.

Good options for the offsite copy include a separate cloud object-storage bucket, a different hosting provider entirely, or encrypted storage you control. Whatever you pick, apply a few non-negotiables:

• Encrypt before it leaves your server. Backups contain user data, password hashes, and config secrets — treat the archive as sensitive and encrypt it at rest.
• Keep it on independent credentials. If a compromise of your main host also unlocks your backups, you have one failure, not two copies.
• Mind jurisdiction and privacy. Where your backup physically sits affects who can compel access to it and under what rules.

This is where an independent, privacy-forward provider earns its place. Holding your offsite copy with a host like LaunchPad Host — offshore, privacy-respecting, and crypto-friendly — keeps that critical third copy outside the same account, infrastructure, and often the same legal jurisdiction as your live site. It is a lawful, sensible redundancy choice: you are not hiding anything, you are simply making sure one ordinary bad day at one provider cannot erase your entire web presence.

How do you know your backups actually work?

You test them. An untested backup is a belief, and disaster recovery is no place for faith. The single most common backup failure is not a missing file — it is discovering, mid-crisis, that the archive is incomplete, corrupted, or impossible to restore against your current environment.

Build a simple verification routine:

1. Schedule test restores quarterly. Spin up a staging site or a local environment and restore your latest backup into it from scratch.
2. Confirm it boots and works. Log in, load key pages, check that images, forms, and any transactions behave — not just that files copied.
3. Time the restore. Your recovery time objective is how long a full restore takes; if it is hours longer than you assumed, fix that before an outage forces the lesson.
4. Watch for silent failures. Check backup logs and alerts. A job that has been quietly erroring for three weeks is worse than no backup, because it feels safe.

Automate the backups, but never fully automate away your attention. Put a recurring reminder on the calendar, run the restore drill, and confirm your offsite copy is current and decryptable. Done consistently, the 3-2-1 rule turns a website catastrophe into a routine, even boring, recovery — which is exactly what you want it to be.