What a website backup should do, and what most of them do instead

Your site goes down on a Sunday and you go looking for the backup. Every WordPress plugin mentions one somewhere in its settings, so it feels like a solved problem. Twenty minutes later you are looking at a page that says “Last backup: 14 weeks ago”, and the safety net you assumed you had turns out to have quietly given way in June.

That gap is common, and it is rarely because nobody thought about backups. It is because a backup that runs is not the same thing as a backup that works.

A backup you have not restored is a guess

Most people’s definition of a backup is a zip file appearing in a folder on a schedule. That file existing tells you almost nothing. It could be corrupt. It could be missing half the site. It could have stopped updating months ago while the plugin carried on reporting success.

The only thing that tells you a backup works is restoring it somewhere and watching the site come back. Not reading that a restore option exists in a menu: doing one, onto a spare domain or a staging copy, and checking the pages load, the images are there, and you can log in. Do that once and you know your backup works. Skip it, and what you have is an untested claim sitting in cloud storage.

Do this every few months, not once. Plugins update, hosting changes, storage providers get swapped out, and any of those can quietly break the process without breaking the schedule.

Off-server, or it does not count

A backup stored in the same hosting account as the site it protects is a second copy of the same problem. If the server fails, gets hacked, or the host suspends the account, the backup goes down with everything else.

This is the single most common gap we find. The backup plugin is switched on, doing its job, faithfully writing files to a folder called backups a few directories over from the site itself. It survives a bad plugin update. It does not survive a compromised server, which is exactly the situation you are most likely to need it for.

A working setup writes to somewhere else entirely: a separate storage provider, a different account, a different company. If you had to explain where your backup lives and the honest answer is “on the same server”, treat that as no backup at all.

Files and the database, both

A WordPress site is two things pretending to be one. The files, themes, plugins, uploaded images, hold the shape of the site. The database holds the content: every post, every page, every order if you sell anything, every setting.

Restore the files without the database and you get an empty shell with no words in it. Restore the database without the files and you get content with no theme to display it in, and often no working plugins either. Some backup tools default to files only, because that is the smaller job and the faster upload. Check yours covers the database, and check the file size looks proportionate to how much content the site holds. A one-page product catalogue backing up to a few kilobytes is a files-only backup with an empty label.

How far back, and how many

A single daily backup answers one question: can you undo yesterday. It does not answer the question that matters most of the time, which is whether you can undo something that has been sitting there quietly for three weeks.

Malware and hacked accounts are rarely noticed the day they happen. Most sites we help after a hack had been compromised for a fortnight or more before anyone spotted it, which means last night’s backup already contains the infection. Restoring it brings the problem straight back.

Retention is what fixes that: daily backups for the last week or two, then weekly ones going back a couple of months. That gives you a point before the problem started, rather than only a point before yesterday.

The one that stopped without telling you

Backup plugins fail quietly more often than they fail loudly. A storage quota fills up. An API key expires. A plugin update changes a setting and the schedule stops without an error appearing anywhere you would see it. The dashboard still shows a green tick because the plugin is reporting on itself, and a plugin that has stopped running cannot tell you it has stopped running.

A better plugin does not fix this. A human looking at the list of dated files, often enough to notice a gap, does.

The five-minute audit

Do this today, before you need it:

• Find the file, not the setting. Open the storage location and look for a backup with today’s or yesterday’s date. “Backups enabled” is a setting. A dated file is evidence.
• Check where it lives. If it is in the same hosting account as the site, it is not off-server. Move it, or add a second copy somewhere else.
• Open one and check it is not files-only or database-only. A file listing that only shows images, or a download that is a few kilobytes for a site with hundreds of pages, is missing half the job.
• Count how many restore points you have. One backup covers you for one day’s worth of problems. You want at least a few weeks of history.
• Restore one, somewhere safe. A spare subdomain, a staging site, anything that is not the live one. If it comes back looking right, you have a backup. Until then, you have a hope.

If any of those five points a gap you did not expect, that is worth fixing this week rather than after the next hosting bill or the next odd email from a customer.

Backups are part of what our Care & Hosting plan handles: stored off the server, covering files and database together, kept for long enough that a slow-burning problem does not outlast your history, for £49 a month.