When a website comes to us from somewhere else, one of the first things we look at is the backups. Usually there is a plugin installed, set up once by somebody and then never looked at again.
The harder question is whether the thing it has been producing would actually bring the site back. That is not the same question, and the gap between the two is where people get caught out.
Worth saying up front: if we host your website, none of this is your job. Your backups run at the server level rather than through a plugin, they are kept off the server they came from, and we are the ones checking them. This piece is about any other website you rely on.
What we found on a site recently.
We were asked to take a copy of a site so the owners had one in their own hands. Reasonable request, and the site already had a well known backup plugin running on it.
From the dashboard everything looked fine. The plugin was installed, configured, and showing a list of previous backups. Nobody had any reason to think there was a problem.
Underneath, three things were wrong. The connection to its cloud storage had failed several weeks earlier and never recovered. Both schedules had quietly reverted to “nothing scheduled”, so no new backup had run since. And of the last backup that did complete, only part had survived: the database was there, but the theme, the plugins and every image on the site were gone.
The part that surprised them most was where that surviving file was sitting. On the same server as the website.
A database on its own will not bring your site back.
It helps to know what a WordPress site is actually made of, because it is two separate things and a backup needs both.
The database holds your words. Pages, posts, settings, users, customer records, orders. It is the content and the memory of the site.
The files are everything else. The theme that makes it look like your business, the plugins that make it do things, and every image and document you have ever uploaded.
A database on its own restores into a site with no design, no functionality and no pictures. The words are all there and nothing works. Files on their own give you a handsome empty shell. You need the pair, and plenty of backups quietly only keep one.
Where it lives matters as much as whether it exists.
A backup stored on the same server as the website protects you from exactly one thing: somebody deleting the wrong page.
It does not protect you from the server failing, the hosting account lapsing, a bill going unpaid, or a falling out with whoever holds the keys. In every one of those situations the backup goes the same way the website does.
The test is simple. If the worst thing you can imagine happening to your website happened tonight, would the backup still exist tomorrow morning? If the answer depends on the same machine, the same login or the same person, it is not really a separate copy.
| Looks like a backup | Actually is a backup |
|---|---|
| A plugin is installed and switched on | A backup finished successfully this week |
| There is a list of old backups on screen | The most recent one has both the database and the files |
| It saves to the website's own server | It saves somewhere the website cannot reach |
| Nobody has reported a problem | Somebody has restored from it and watched it work |
Three questions worth asking today.
You do not need to understand any of the technology to work out whether your backups are real. Three questions will tell you, and you can ask them of whoever looks after your site.
When did one last finish successfully? Not when was it set up, and not whether it is turned on. When did one actually complete. If nobody can answer with a date, that is the answer.
Where does it live? If it is on the same server as the website, it is a convenience, not a safety net. A real backup sits somewhere separate, ideally on an account the website itself has no access to.
Has anyone ever restored from it? This is the one people skip, and it is the one that counts. A backup that has never been tested is a file of unknown quality. You find out whether it works on the worst possible day, or you find out on a quiet Tuesday when it does not matter.
Why backups fail quietly.
Backups rarely stop with a bang. Almost always it is something small and undramatic.
A connection to cloud storage expires and needs re-authorising. Somebody changes a password on the account the backups were going to. The server runs low on disk space and the job stops halfway. A plugin update resets a setting nobody thought to check.
None of that produces an alarm. The dashboard still looks the same, the old backups are still listed, and everything appears healthy right up until the moment you need it. That is precisely why the three questions matter more than the plugin you chose.
Backups are part of our managed hosting rather than an add-on or a plugin you have to keep an eye on. Every site we host is backed up daily, kept off the server it came from, and we have restored from those backups when clients have needed them. If you are not sure what is happening with another website you rely on, ask us and we will tell you straight.
The bottom line
Having something that calls itself a backup is not the same as having a backup, and the difference only ever shows up at the worst possible moment.
Go and ask the three questions. When did one last finish, where does it live, and has anyone restored from it. It takes five minutes, and either you will get three good answers and never think about it again, or you will find something well worth knowing now rather than later.
