30% of people have never backed up their data. Among those who have, many have never tested whether the backups actually work. WordPress backups are the single cheapest form of insurance a business site can carry — and one of the most commonly misconfigured, misunderstood, or quietly neglected.

This guide covers the mechanics of a genuine backup strategy: what to back up, how often, how long to keep it, where to store it, how to test restoration, and the specific weaknesses in the backup services most hosting providers include as standard.

What a WordPress backup actually contains

A complete WordPress backup is more than a copy of the files. It must include:

  • The database — all posts, pages, products, orders, users, settings, comments, and metadata. On WooCommerce sites, this is where the orders and customer data live.
  • The wp-content directory — themes, plugins, media uploads, and any custom files. Uploaded images and customer-supplied files (attachments, invoices) live here.
  • WordPress core files — technically restorable from WordPress.org, but included in a complete backup for faster recovery.
  • wp-config.php — contains database credentials, keys, and any custom constants.
  • .htaccess or equivalent server config — redirects, security rules, and LiteSpeed/Apache configuration.

A “backup” that only captures the database, or only the files, is incomplete. A working restoration needs both. Many cheap backup plugins default to database-only backups for speed; this is dangerous and usually not obvious until a restoration is attempted.

The 3-2-1 rule

The industry-standard model for resilient backups is 3-2-1:

  • 3 copies of your data in total
  • 2 different media or storage locations
  • 1 copy stored off-site

For a WordPress site this typically translates to: the live site (copy 1), a backup held on the server or in the hosting account (copy 2), and an off-site cloud backup in a separate provider such as AWS S3, Backblaze B2, or Google Cloud Storage (copy 3). The point is that no single failure mode can destroy all three copies simultaneously. A server failure takes out copies 1 and 2 but leaves 3 intact. A hosting account compromise (attacker changes password) takes out copy 1 but leaves 2 and 3 recoverable.

A critical implication: backups stored on the same server as the live site are not real backups. If the server fails, both are lost. If the server is compromised, the attacker can destroy both. Many cheap hosting plans provide “daily backups” stored in a backup/ folder on the same server — these meet the technical definition of a backup but provide almost none of the protection of a real off-site copy.

How often to back up

Backup frequency should match the velocity of meaningful change on your site and the business cost of losing recent data. Three categories:

Content-only sites (brochure, portfolio, marketing)

Daily backups are adequate. Content changes are typically batched (you edit a page, you publish a blog post) and a day’s worth of lost editing is an inconvenience, not a disaster.

Active content or lead-generation sites (blogs, consultancy, contact-heavy)

Daily backups are the minimum. If contact form submissions or comments matter, consider twice-daily or every-six-hours. Losing a week of incoming enquiries is usually more expensive than the additional storage cost.

WooCommerce stores and transactional sites

Daily is inadequate. A store taking 50 orders per day loses up to 50 orders, customer addresses, and payment records with a daily backup taken at 3am after disaster strikes at 2:59am. Real-time backups or hourly incremental backups are appropriate. Some backup services offer continuous replication — effectively zero-data-loss protection — at a cost that is trivial compared to the risk.

A useful question: if you restored from your most recent backup right now, what would you lose? If the answer is uncomfortable, your backup frequency is wrong.

How long to retain

Common retention defaults are too short. Most hosting providers and backup plugins ship with 7-14 day retention as standard. That window is shorter than the typical malware discovery time.

Realistic retention for business WordPress sites:

  • 30 days minimum for standard business sites. This covers most malware infections (typically discovered within 2-3 weeks of compromise) and provides a comfortable recovery window for accidental content deletion or damage.
  • 60-90 days for WooCommerce stores. Card transaction dispute periods and chargeback windows can extend past 30 days. Sufficient retention lets you reconstruct order state from a backup predating a dispute.
  • Annual or multi-year monthly archives for sites subject to regulatory retention requirements (healthcare, legal, financial services, public sector — see our GDPR hosting responsibilities guide for related compliance detail).

The cost of extended retention at cloud storage rates is negligible — typically £5-£20 per month for multi-gigabyte WordPress sites. The cost of discovering a compromise on day 40 when your retention is 30 days is potentially catastrophic.

Where to store backups

Storage location matters as much as frequency. In order of resilience:

  • On-server — same physical server as the live site. Convenient, fast to restore from, destroyed by any event that takes out the server itself. Useful as a fast-access layer, not as primary backup.
  • Same provider, different region — hosting account includes off-server storage in a different datacentre. Better than on-server. Still vulnerable if your account is compromised and the attacker can delete from both.
  • Different provider (S3, B2, GCS) — completely independent credentials, different billing, different operator. True off-site. The 3-2-1 rule’s “1 off-site” copy is almost always this.
  • Immutable storage (S3 Object Lock, B2 with retention) — off-site AND cannot be deleted or overwritten for a specified duration, even by whoever holds the credentials. This is the strongest protection against ransomware that targets backup systems.

For a typical business WordPress site, a daily off-site backup to S3 or Backblaze B2 with 30-day retention costs under £10/month and provides the protection most sites actually need. For WooCommerce stores, hourly backups to the same storage with 90-day retention is typically £15-£30/month.

Backup testing — the step almost everyone skips

A backup you have never tested is a backup of unknown quality. “Backup was successful” in the logs tells you the process completed without errors — it does not tell you whether the resulting archive is restorable.

The testing routine that works:

  1. Quarterly full restoration to a staging environment. Take your most recent backup, restore it to a staging subdomain, and confirm the site runs correctly. This catches problems with backup integrity, database dumps, file corruption, and missing components.

  2. Verify critical functionality post-restore. For a content site: page rendering, admin login, search. For WooCommerce: product pages, cart, checkout flow, admin order listing. The backup succeeded only if the restored site actually works.

  3. Time the restoration. How long does a full restore take? A 20GB WooCommerce store can take hours to restore from some backup services. If that exceeds your acceptable downtime, either move to a faster backup service or architect around the restore time.

  4. Document the process. The person who needs to restore at 2am in a panic is probably not the person who set up the backups. Written runbooks matter.

Most “my backup didn’t work” stories are actually “my backup was never tested and silently broke six months ago.”

The hidden weaknesses in hosting-provided backups

Budget hosting backup services frequently have serious limitations that only become obvious when needed. Five to check before relying on yours:

Where are the backups stored? If the answer is “on the same server” or “in your hosting account”, they are not real off-site backups. A server failure or compromise affects both.

How frequent is the schedule? Weekly backups are inadequate for any business site. Daily is the minimum. Many hosts advertise “daily backups” but run them only on the previous night — meaning you can lose up to 24 hours of data.

What is the retention? If the answer is “7 days” or “14 days”, that is shorter than typical malware discovery time.

Is there a restoration SLA? Some hosts offer backups but have no committed restore time — a backup you cannot access quickly during a crisis is of limited use.

Is restoration included or charged? Some budget hosts provide backups for free but charge £50-£200 for actually restoring from them. This pricing model turns up in the fine print and catches people during emergencies.

If your current host cannot clearly answer all five, that is material information about your actual risk exposure.

The real cost of inadequate backups

The full cost of recovering a WordPress site without recent working backups includes:

  • Design and development to rebuild — £2,000-£10,000+ for a custom site, more for large or complex sites
  • Content recreation — weeks of work for a content-heavy site, typically impossible to restore fully from memory or web archives
  • Customer and order data loss — for WooCommerce stores, the accumulated customer relationships and order history is often irreplaceable
  • SEO rankings lost — months to recover organic traffic after a prolonged downtime or rebuilt site
  • Trust and reputation damage — customers who experienced downtime or lost accounts may not return
  • Business operation disruption — the opportunity cost of running the recovery project instead of normal business

Against these costs, even premium backup services with tested restoration represent a trivially small insurance premium. The question is never whether backups are “worth it” — it is whether yours actually work when you need them.

A backup strategy audit

Use this checklist to assess any WordPress site:

  • Full backup (database + files) runs automatically on a schedule appropriate for the site’s change velocity
  • Backups are stored off-site, on a provider separate from the live hosting
  • Retention period is at least 30 days (longer for transactional sites)
  • Backup integrity is verified automatically (not just “process completed”)
  • Restoration has been tested within the last 90 days, end-to-end
  • The restoration runbook exists in writing and has been followed by someone other than the original author
  • The time to full restoration is known and acceptable for the business
  • Backup credentials and access are documented securely

If any of these are unknown or “no”, that is the first item on the improvement list. Backups are only useful if they actually work when needed — everything else is theatre.

On managed hosting built for business WordPress, daily off-site backups with 30-day retention should be standard, one-click restoration should be available, and the provider should be able to confirm they routinely test customer restorations. See how our approach compares to shared hosting on this specific dimension, and read our data protection and GDPR guide for the regulatory angle on backup retention.