Website Backups: What a Proper Backup Strategy Looks Like

A proper website backup strategy is not "the host does backups". It is a short set of decisions: what gets backed up, how often, where the copies live, how long they are kept, and how you know they can be restored. Get those five right and a hack, a failed update or a deleted page becomes an inconvenience rather than a crisis.

The fifth one — proving a restore works — is the one almost everyone skips, and it is the only one that tells you whether the other four worked.

What needs backing up?

A WordPress site is two things that must be backed up together:

A database backup without the files, or the reverse, is not a complete recovery. WordPress core, plugins and themes can be reinstalled from their sources, but your uploads, custom code and configuration cannot.

Beyond the site itself, keep a record of:

• DNS records — a screenshot or export of every record at the registrar or DNS provider. Losing these is how email stops working after a migration.
• Logins and licence keys — in a password manager, not in the site.
• Third-party configuration — form integrations, payment gateway settings, analytics IDs.

For a static or Next.js site, the code should already live in version control, so the backup focus shifts to any database, content management system or uploaded media the site depends on.

How often should you back up?

Match the frequency to how much change you could afford to lose. That figure — how much recent work you are prepared to redo — is the whole basis for the decision.

Separately from the schedule, take a manual backup immediately before any update, migration or significant change. That is the backup you are most likely to need.

Where should backups be stored?

Not only on the same server as the site. If the server fails, the account is suspended, or an attacker gets in and deletes everything they can reach, backups stored alongside the site go with it.

The widely used 3-2-1 rule is a good guide:

• 3 copies of the data (the live site plus two backups)
• 2 different types of storage
• 1 copy off-site, somewhere the hosting company does not control

In practice, for a small business site that usually means: the host's own daily backups as the first layer, plus a backup plugin or service sending copies to independent cloud storage such as Amazon S3, Backblaze B2, Google Drive or Dropbox. Use separate credentials for that storage, so a compromised website cannot delete its own off-site backups.

How long should backups be kept?

Problems are often discovered late. A hack can sit quietly for weeks; a page deleted by mistake might not be missed for a month; a plugin can corrupt data gradually. If you only keep seven days of backups, all seven might contain the problem.

A sensible retention pattern:

Storage is cheap for most small sites. A short retention period is rarely a cost decision; it is usually just a default nobody changed.

How to test a restore

A backup you have never restored is a hope. Testing proves three things: the backup is complete, it is not corrupted, and someone knows the restore procedure before they need it under pressure.

1. Create a staging site — most managed hosts offer one, or use a subdomain with search engines blocked.
2. Restore the most recent backup to staging using the same tool and process you would use in an emergency.
3. Check the site loads, including pages, images and the admin area.
4. Check recent content is there — the last post, the last order, a recent form entry.
5. Note how long it took. That is your real recovery time, and it is worth knowing before an outage.
6. Delete or lock the staging copy afterwards if it contains personal data.

Monthly is ideal for a site that earns money; quarterly is the minimum. The WordPress maintenance monthly checklist puts the restore test alongside the other monthly jobs.

Two numbers worth knowing

IT teams talk about two measures, and they are useful at any size:

• Recovery point — how much data you could lose. Daily backups mean up to a day.
• Recovery time — how long until the site is back. Your restore test tells you this.

Say a shop takes orders through the evening and backs up at 2am. If the server fails at 9pm, up to 19 hours of orders exist only in emails and the payment provider's dashboard. Whether that is acceptable is a business decision. If it is not, the backup frequency needs to change — not the hope that it will not happen.

Website backup tools: plugin, host or service?

Most small business sites are well served by host backups plus one off-site tool. Running three backup plugins at once does not triple the safety; it slows the site and multiplies the configuration to check.

Signs your backups are not working

Backups fail quietly. Watch for:

• backup notification emails that stopped arriving and nobody noticed
• backup files that are suspiciously small, or the same size every day on a site that changes
• a plugin that reports success but whose off-site storage connection expired months ago
• off-site storage that has hit its quota, so new backups are silently skipped
• backups that exclude the uploads folder to save space

Each of these is caught by a restore test. None of them is caught by looking at a dashboard that says "last backup: successful".

Backups and personal data

Backups contain everything the site contains, including enquiries, customer accounts and orders. Under UK GDPR, that data needs the same care as the live site: stored securely, kept no longer than necessary, and accessible only to people who need it. Use storage with encryption and strong access controls, and do not leave old staging copies full of customer data lying around. UK website legal requirements covers the wider data protection picture.

Where this fits

Backups are the safety net under everything else in website maintenance. They are what makes it safe to update WordPress, what turns a hacked site into a recoverable one, and what you lean on when choosing or changing hosting.

If you would rather someone else ran the backups and proved the restores, that is a core part of the website maintenance service, where restores are tested to staging on a schedule.