The backup that was not there
A client's site is hacked on a Sunday night. On Monday the developer goes to restore last week's backup. The backup plugin shows green ticks for every night. The restore fails: the database file is empty, and has been since the host changed a setting months ago. The files backup excludes the uploads folder because it grew too large for the plan.
The site is eventually rebuilt from an older backup found on the host, with some content lost. The client asks how often the backups were checked. The honest answer is never.
Every other site the studio looks after uses the same plugin, set up the same way, on the same kind of hosting. Nobody knows how many of those backups would restore either.
Why backups fail silently
- Backup tools report that a job ran, not that the result can be restored.
- Exclusions set to save space, such as large upload folders, are forgotten.
- Storage fills up and older backups are deleted or new ones fail partway.
- Hosts change their configuration, breaking database dumps.
- Restoring is a manual, time-consuming job, so it is only done in a crisis.
A backup nobody has restored is a hope, not a backup.
What an untested backup costs
When something goes wrong, the studio discovers the problem at the worst moment, with a client waiting and a site down. Content and orders can be lost. The client relationship is damaged, especially if backups were part of a paid maintenance plan. The studio's own confidence in its maintenance service is shaken.
The restore testing we build
- Every client site is listed with where its backups are made and stored, whether by the host, a plugin, a management tool or your own scripts.
- On a schedule you choose, a recent backup for each site is taken and restored to an isolated, temporary environment that search engines and the public cannot reach.
- The restored site is checked: database present and connected, key pages load, recent content present, uploads folder complete.
- The size and age of the backup are compared with previous ones, and sudden drops are flagged.
- Results are recorded per site: pass, fail with the reason, or not tested.
- Failures alert the developer responsible, and the temporary environment is removed after the test.
- The results feed into the client maintenance report, so clients see that backups are tested.
| Check | What it catches |
|---|---|
| Database present | Empty or failed database dumps |
| Key pages load | Broken or incomplete backups |
| Recent content present | Backups that stopped updating |
| Uploads complete | Folders excluded to save space |
| Size compared with previous | Sudden changes worth investigating |
Tests rotate across sites, so every site is tested regularly without restoring all of them at once.
E-commerce sites get an extra check that recent orders are present in the restored database, because an online shop that loses a day of orders has a much bigger problem than a brochure site that loses a blog post. Sites with very large media libraries can be tested with a sample of the uploads rather than a full copy, with the sample chosen at random each time so that gaps still show up over a few runs.
Knowing the backups work
Each week, a batch of sites is test-restored overnight. The developer sees the results in the morning. One site fails because a new plugin stores files outside the backed-up folder; the backup settings are updated that day. When a client site does need restoring, the developer knows the backup works because it was tested recently.
When did you last restore a backup?
- Client site backups run, but have never been test-restored.
- Backup tools show green ticks you have never verified.
- Large folders have been excluded from backups to save space.
- You are not sure what a restore would involve for each site.
- Maintenance plans promise backups without mentioning testing.