A real website backup follows the same rule US federal cybersecurity guidance (CISA) recommends for any business: three copies of the data, on two different types of storage, with one copy kept off-site from the rest. Most sites that call themselves "backed up" only have the first two — a live copy and a same-host snapshot — which means the one incident that takes out the host takes out the backup with it.
Our own website maintenance guide lists "tested backups, not just taken ones" as one line among several. It deserved its own explanation — the gap between a backup that exists and a backup that actually saves a site the day it's needed is bigger than a checklist item suggests.
The 3-2-1 shape, applied to a website
Three copies: the live site is the first. An automated daily backup, taken by the host or a backup plugin, is the second. A separate off-site copy — pushed to a different provider or a cloud storage bucket entirely, not just a different folder on the same server — is the third. Two different storage types matters because a single failure mode (a bad RAID array, a corrupted database export) shouldn't be able to take out more than one copy at once. One copy off-site matters because hosting accounts get suspended, hacked, or shut down by the provider without warning, and a backup stored in the same account has no independence from whatever just happened to it.
The practical version for most small business sites: keep the host's own automated backup running as copy two, and add a second automated job — most backup plugins and managed hosts support this directly — that pushes a copy to a separate cloud storage account weekly at minimum, daily if the site takes orders, bookings, or any data a business can't afford to lose a week of.
A backup that's never been restored is a guess
CISA's own guidance for businesses is specific here: test that a backup can be restored both fully and partially, and confirm data can be rolled back at least seven days if needed. Taking a backup is one script running correctly. Restoring one is a different process entirely, and the only way to know it works is to actually run it — onto a staging copy of the site, never the live one — and check the result loads and the data is intact.
The failure mode this catches is common and invisible until it isn't: a backup job that's been silently failing for weeks, a database export that's technically there but corrupted, a file backup that excludes the one folder that turns out to matter. None of that shows up by looking at a dashboard that says "backup completed" — it only shows up in an actual restore. A quarterly restore test onto staging is enough to catch it before the day it's needed for real.
How this fits a maintenance plan
Backups sit in the same "ongoing, keeps expiring" bucket as certificate renewal and patch cadence, covered in more detail in our guide on how often a website should actually be updated — the backup itself doesn't degrade, but an untested one silently stops being trustworthy the moment something about the site's structure or database changes and nobody re-checks it. That's why a real maintenance plan logs backups taken and restore tests run, the same log we cover in our maintenance guide — not just a setting turned on once at launch and never looked at again.
Frequently asked questions
What is the 3-2-1 backup rule?
Three copies of your data, on two different types of storage media, with one copy kept off-site. CISA recommends it as the baseline standard for US small and medium businesses, and it applies just as well to a website: the live site is copy one, an automated daily backup on the host is copy two, and a separate off-site copy — a different provider or storage service entirely — is copy three.
Why isn't a backup on the same host enough?
It protects against the most common failure — a bad update, a hacked plugin, an accidental deletion — but not against the host itself going down, being compromised, or suspending the account. If the backup lives in the same account as the site it's protecting, one incident can take out both at once.
How do I know if a backup actually works?
Restore it somewhere and check the result — a staging copy of the site, not the live one. CISA's own guidance for businesses is to test that a backup can be fully and partially restored, and that data can be rolled back at least seven days if needed. A backup that has only ever been taken, never restored, is an assumption, not a safeguard.
How often should a website be backed up?
Daily, automatically, with no one having to remember to trigger it — the same automation-over-memory principle that applies to security patches. A site that takes orders, bookings, or form submissions loses real data for every hour between the incident and the last backup, so the gap matters more than the schedule looking thorough on paper.
Does this apply to a business app the same way it applies to a website?
The 3-2-1 principle is the same, but the source of truth usually moves — most business apps store their real data in a backend database or cloud service rather than the app itself, so that's what needs the off-site copy and the restore test, not the app binary.