Advertising disclosure: We may earn a commission from links on this site. Commercial relationships can affect placement. Product facts, limitations, and source dates remain part of our editorial record.

How funding works
Web Hosting

How to Build a Website Backup Plan for a Small Business

How to build a small business website backup plan: the 3-2-1 rule, what to copy, recovery objectives, off-site copies, and restore testing.

Review sources
Research standard

Facts that can change should include a source and check date. Benchmark claims should state the plan, region, method, and test period.

A website backup plan should identify what is copied, where copies are kept and how restoration is tested. Set the schedule according to the amount of recent data your business can afford to lose.

What You Are Actually Backing Up#

A complete backup has two distinct parts, and missing either one makes the other useless on its own. The first is the relational database, which holds your content, site settings, user accounts, and — if you sell anything — orders and customer records. The second is the filesystem: the application's core scripts, theme templates, plugin files, uploaded media, and configuration files.

A common failure mode is backing up one and assuming the other is included. Files without a database give you a site with no content; a database without files gives you content with nothing to render it. Note where each part lives in your setup, because some managed hosts keep uploads on a separate store from the rest of the filesystem.

Apply the 3-2-1 Rule#

The widely used resilience guideline is 3-2-1: keep three copies of your important data, on two different types of storage, with at least one copy held off-site. The point of the third copy is independence. A backup stored on the same server, or in the same provider's data center, shares that provider's failures — an account suspension, a hardware fault, a credential compromise, or a ransomware event that encrypts everything it can reach.

For a website, off-site usually means a cloud storage bucket or a cold archive controlled by your business rather than by your host. The UK's National Cyber Security Centre makes the same point in plain terms in its small business guidance: a backup you cannot reach when the primary system is unavailable is not much of a backup.

Set Frequency and Retention#

How often to back up follows from how much change the site absorbs and how much loss is acceptable. A site taking orders and comments every hour justifies daily database backups or more; a mostly static brochure site may be well served by a weekly copy plus a manual one before each content change. Retention should be long enough that a subtle problem — a corrupted table, a malicious script inserted quietly — is still recoverable by the time anyone notices. Keeping several generations rather than only the most recent copy is what makes that possible.

Define What Recovery Means Before You Need It#

Two numbers turn a vague intention into a plan. The recovery time objective is how long the business can tolerate the site being unavailable. The recovery point objective is how much recent data you can afford to lose, measured in hours or days. Together they set your backup frequency and your storage choices.

Both numbers are business decisions rather than technical ones, and writing them down makes the rest of the plan easy to evaluate. A backup schedule that would leave you restoring a week-old database does not meet a recovery point objective measured in hours, whatever the hosting feature list says.

Automate, and Keep a Copy the Host Does Not Control#

Host-managed snapshots are genuinely useful — they are quick to create and quick to roll back to. They are not a plan by themselves, because they live inside the account they are meant to protect. CISA's small business resources frame the risk simply: rely on a single system, and that system becomes your single point of failure.

Automate the off-site copy rather than relying on someone remembering. Whatever the mechanism — a plugin writing to external storage, a scheduled export, a script run on a timer — the test is that it runs without a person present and reports when it fails. A silent backup job that stopped weeks ago is worse than no job at all, because it produces confidence without coverage.

Test Restores on a Schedule#

A backup is only as reliable as the recovery process behind it. Restore a copy to a staging environment on a regular schedule and confirm the site comes up, the content is current, and the database connects. WordPress's backup documentation for advanced administrators covers the mechanics, and the same discipline applies to any platform.

Treat the drill as the moment you discover the missing piece — the configuration file that was excluded, the export that truncated, the credentials nobody wrote down. Document what you did, how long it took, and what broke, then compare the elapsed time against your recovery time objective. Adjust the plan, not the expectation.

Write the Plan on One Page#

Keep the plan short enough that someone else could follow it on a bad day. Include where each copy lives, how often it is created, how to restore, who is responsible, and who to call. Revisit it once a year and after any significant change to the site. Boring, scheduled, and independent of any one provider is exactly what a small business backup plan should look like.

Sources

  1. CISA – Small and Medium-Sized Business Data Backup Guidance Checked 2026-08-28
  2. UK National Cyber Security Centre (NCSC) – Backing Up Your Data Checked 2026-08-28
  3. WordPress Developer Documentation – WordPress Backups Checked 2026-08-28