The 3-2-1 Backup Rule for Website Owners

The 3-2-1 backup rule says keep three copies of your data, on two different kinds of storage, with one copy offsite. Applied to a website backup, that means the live site, a copy at your host, and a copy somewhere your host cannot touch. This guide turns the rule into a working setup for a small site.

This guide focuses on the checks a small-site owner can make safely. It also points out where a host, registrar, email provider, or developer needs to take over. Read how to choose a web host if you need the broader setup, and our migration guide before changing live infrastructure.

What a website backup must include

A complete website backup covers files, the database, email if it lives at the host, and a copy of your DNS records. Miss the database and you have backed up the furniture but not the house.

Protect the account that can change or delete backups first — a unique password and multi-factor authentication where available. An attacker who owns your control panel owns your backups too, which is exactly the failure the rule is built to survive.

The 3-2-1 backup rule, unpacked

Three copies means the live site counts as one, so you need two real backups. Two kinds of storage means those backups should not share a fate — a host-run backup and a copy in separate cloud storage, for instance. One offsite backup means at least one copy lives outside the production account entirely, so a suspended account, a billing dispute, or a compromise cannot take the site and its safety net together.

Keep that offsite copy outside the production account and practice a restore. A backup that has never been opened is a hope, not a recovery plan.

Test the restore, not just the backup

When an incident happens, preserve the evidence, restrict access, and work from a known-good copy. Avoid making a string of unexplained changes that destroy the trail you need to understand the problem.

Test the restore path with the most consequence first. For a store, that is the database with orders in it. For a blog, it is the uploads folder. A restore test should answer one question — can I get this back? — rather than produce a vague impression.

When to stop and ask for help

Stop when the next action could overwrite data, change production mail, or remove access to the account. Send support the domain, time in UTC, exact error, and the changes you made. Include a screenshot when it shows the error, but do not include private keys, passwords, or full payment information.

Let's Encrypt documentation has useful background if certificates are part of your restore plan: Let's Encrypt documentation. Use it to understand the terms, then return to the small, reversible next step.

A sensible maintenance habit

Put the backup schedule, storage locations, and the date of your last restore test in a short maintenance note — the 3-2-1 backup rule only holds if it survives the week you set it up. Backup problems repeat because nobody remembers which account holds which copy or when the routine last ran. A dated note turns the next incident into a lookup instead of an investigation.

Keep the change auditable

Use a short before-and-after record. Write the setting you found, its old value, the exact time you changed it, and the result of the test. If the change has a delay, such as a scheduled backup window, write the time you expect the next copy to exist. This record is useful even when everything works. A few months later, it tells you why a setting has an unusual value.

Do not confuse an account dashboard with evidence of a working backup. A dashboard can show that a job ran. You still need the file to exist, at a plausible size, and to open correctly. Check the copy itself, not the green tick next to it.

If you hand the task to someone else, give them the record rather than a conclusion. "We have backups" is hard to verify. "The nightly copy lands in this bucket, the last restore test was on this date, and here is the result" gives the next person a useful starting point.

One last check

Before you close the ticket or move to the next task, open the most recent backup and confirm it contains what you expect — files and database, at a plausible size, from the right site. If anything is off, note the difference and keep troubleshooting from that point. A quiet confirmation now is much easier than discovering an empty archive during an outage.

Leave a useful handoff

Save the backup locations, schedule, and last test result with the date and accounts involved. If someone else needs to run a restore, they should be able to do it without reconstructing the whole arrangement from browser history.

Bottom line

The 3-2-1 backup rule works because it survives correlated failure: three copies, two kinds of storage, one offsite backup your host cannot touch. Automate the copies, test a restore on a schedule, and treat the offsite leg as the one that actually saves you.

Frequently asked questions

Do I need the full 3-2-1 backup strategy from day one?

No. Add one leg at a time — start with the offsite copy — test it, and keep your existing backups running until the new routine is stable.

What information should I give hosting support about a failed backup?

Give the domain, the backup job or tool involved, UTC time, exact error text, and steps already tried. That is usually enough for support to find the relevant logs.

Should I verify a website backup before making site changes?

Yes. Download or verify a recent backup before edits that affect files, databases, email, DNS, or software versions.