Website Backups You Can Restore: The 3-2-1 Rule for Business Sites

Ask a business owner whether their website is backed up and the answer is usually yes. The host takes backups, or a plugin does, or the developer has a copy somewhere. Ask when the last restore was tested, and the answer tends to get vaguer.

That gap matters because a website backup is only useful at the moment you need it, and that moment is usually a bad one: a failed update, a deleted page, a compromised account, or a hosting problem. This article draws on guidance from the UK’s National Cyber Security Centre (NCSC), a backup paper produced for the US Computer Emergency Readiness Team (US-CERT), and the WordPress project’s own documentation to set out what a website backup has to contain and where its copies should live.

---

Why “the host has backups” isn’t enough

Hosting backups are a useful layer, but they share two weaknesses with the site itself. They often live with the same provider, so a problem with the account can affect the site and its backups together. And they can take time to retrieve. The WordPress project’s documentation on backups notes that most hosts back up the entire server, but that requesting a copy of your site from those backups takes time, while a speedy recovery is critical.

The more serious risk is a backup that is connected to the thing it’s meant to protect. In a 2019 blog post, Offline backups in an online world, the NCSC reported seeing numerous ransomware incidents in which the attack encrypted not only the original data but also the connected USB and network drives holding backups. Incidents had also compromised connected cloud storage locations that contained backups. The NCSC’s guidance on mitigating malware and ransomware attacks draws the conclusion directly: don’t rely on two copies on a single removable drive, or on multiple copies in a single cloud service.

What goes wrong when backups are an afterthought

1. The backup is incomplete. The files were saved, but the database that holds the pages and settings wasn’t, or the reverse.
2. The backup copied the problem. An automatic backup ran after the site was damaged and replaced the last good copy.
3. Nobody knows how to restore it. The copy exists, but the steps, credentials, or software needed to rebuild the site from it don’t.

---

What the 3-2-1 rule asks for

The 3-2-1 rule is the most common starting point for backup planning, and both government sources used here describe it.

The US-CERT paper Data Backup Options, written by Paul Ruggiero and Matthew A. Heckathorn and produced by Carnegie Mellon University for US-CERT in 2012, states it this way:

• 3: Keep three copies of any important file, one primary and two backups.
• 2: Keep the files on two different media types to protect against different types of hazards.
• 1: Store one copy offsite, outside your home or business facility.

The NCSC’s 2019 post gives a slightly different wording: at least three copies, on two devices, and one offsite. The NCSC also notes that the rule scales well, including the use of the cloud for the offsite copy.

Where the rule falls short

The same NCSC post points out a gap. The 3-2-1 rule doesn’t require any of the copies to be offline. If all three copies are reachable from the live site or from an account an attacker controls, all three can be damaged at once. That’s why the NCSC adds an offline rule: at least one backup should be disconnected at any given time, connected only when it’s needed.

Cloud storage complicates this, because it can’t simply be unplugged. The NCSC’s suggested equivalent is to limit which devices hold credentials to the backup storage, keep those credentials inactive when the storage isn’t in use, and, where the service supports it, allow backup clients only to add new backups rather than modify existing ones.

The US-CERT paper, now published by the US Cybersecurity and Infrastructure Security Agency (CISA), describes a related failure in plainer terms. Rolling backups, which automatically and periodically update backup files with the latest versions of the primary files, can silently propagate any corruption or malware in the primary files to the backup files. A backup that always mirrors the live site will also mirror its damage.

---

What a complete website backup includes

A website isn’t one file. The WordPress documentation makes the point clearly for the platform it covers: a site backup has two parts, the database and the files, and you need both to fully restore a typical WordPress site. Backing up the files does not back up the database, because the database lives in a separate system outside the site’s directory.

The same split applies, in different forms, to most business websites. Think of it as an inventory of everything you would need to rebuild the site on a new server.

Website backup inventory

• Code and templates: the theme, plugins, or application code, ideally also kept in version control.
• Database: pages, posts, settings, and user accounts for any site built on a content management system.
• Uploaded media: images, PDFs, and other files added through the site’s admin area.
• Configuration: environment settings, server rules, and configuration files such as wp-config.php on WordPress, stored securely because they often contain credentials.
• Form submissions: inquiries stored on the site or in a form service, if they aren’t also delivered elsewhere.
• DNS records: a current export or written record, since rebuilding a site doesn’t help if the domain no longer points to it.
• Access details: who controls the hosting, domain, and backup accounts, kept somewhere that doesn’t depend on the website being up.

For a static site generated from a code repository, the repository already covers the code and much of the content. It usually doesn’t cover the last four items on the list, which is where static sites tend to have gaps.

Keeping files and database in step

The WordPress documentation recommends treating the files and database as one backup set, created around the same time. Its suggested order is to back up the database first, then the files, and to restore the files first, then import the database. A database restored against files from a different week can break pages or lose uploads, even when both backups are individually sound.

“The question isn’t whether you have a backup. It’s whether you’ve ever rebuilt the site from one.”
— Windware Studio Practice Note

---

How often to back up, and how long to keep copies

Backup frequency is a decision about how much recent work you can afford to lose. A site whose content changes monthly can tolerate a weekly backup. A site that takes bookings or publishes daily can’t.

The WordPress documentation offers a simple starting point: weekly backups for smaller sites with fewer posts, daily for high-activity sites. It also advises backing up before every upgrade, and keeping at least three to five recent backups in different locations, such as one on the hosting server, one in cloud storage, and one on a local computer.

Retention needs a second thought. In its 2024 principles for ransomware-resistant cloud backups, the NCSC recommends keeping backups for a fixed time period rather than a fixed number of copies. If a service keeps only the last five backups, an attacker, or a broken update that runs for five nights, can push every good copy out. The NCSC’s example of a time-based policy is keeping daily backups for a month and monthly backups for a year.

Site type	Content changes	Reasonable backup frequency	What to watch
Brochure or portfolio site	Occasionally	Weekly, and before every update	Media uploads and configuration, not only code
Service site with blog or CMS	Weekly	Daily database, weekly files	Files and database captured as one set
Site with bookings or stored inquiries	Daily	Daily or more often	Data received between backups
Static site from a repository	Per deploy	Each deploy, plus external data	DNS, form data, and environment settings

These frequencies are starting points drawn from the guidance above, not rules. The right schedule depends on what the site collects and how much rework a loss would cause.

---

Testing the restore

Every source used here ends in the same place. The NCSC’s 2019 post says backups should be tested regularly to check they work as expected. Its 2024 principles call for regular restore testing as part of monitoring, partly so that a corrupted backup is noticed before it’s needed. The WordPress documentation recommends occasionally backing up automated backups with a manual one, to confirm the automated process is working.

A restore test for a business website doesn’t need to touch the live site.

A simple restore drill

1. Pick a recent backup set from the offsite or offline copy, not the one sitting next to the live site.
2. Restore it to a staging location, such as a temporary subdomain or a local environment.
3. Check the pages that matter: the homepage, a service page, the contact form, and a page with uploaded images.
4. Time the process. If it takes a full day, that’s how long the site would be down in a real incident.
5. Write down what was missing, whether a credential, a file, or a step, and fix the backup process before the next drill.

What testing can’t guarantee

A successful drill shows that a particular backup could be restored under calm conditions. It doesn’t prove that every backup is clean. In its ransomware guidance, the NCSC warns that ransomware can sit in a system for a while and replicate into backups before it’s discovered, and advises scanning backups for malware before restoring and connecting them only to known clean devices. For most small business sites, the practical response is retention: keeping older copies long enough that a clean one still exists when a problem is finally noticed.

---

Practical takeaways for your next website

1. List what the site is made of. Code, database, media, configuration, form data, and DNS all need a place in the backup plan.
2. Apply 3-2-1, then add offline. Three copies, two kinds of storage, one offsite, and at least one that isn’t reachable from the live site or its admin accounts.
3. Back up the database and files together. Treat them as a single set so a restore doesn’t mix data from different days.
4. Keep by time, not by count. A retention window, such as daily copies for a month and monthly for a year, protects against a run of bad backups.
5. Rehearse the restore. Restore to staging on a schedule, time it, and fix whatever the drill exposes.

---

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help you build a site with a backup and restore plan that’s been tested before you need it.

• Explore Our Services: Web Design · Web Development · Website Redesign
• Start a Conversation: Tell us about your project via our Contact Form or email us directly at [email protected].