Almost everybody has backups. Far fewer have restores. The distinction only becomes interesting on the day it matters, which is a poor time to discover it.
How healthy-looking backups fail
The database was not included. Common with file-level backups on WordPress sites. You have every file and none of the content, which is the wrong half.
The archive is corrupt. It completed, it has a plausible file size, and it will not extract. Nothing reports this until you try.
It backed up the broken state. The site was compromised or damaged on Monday. Nobody noticed until Friday. The retention is three days. Every backup you hold contains the problem.
It is on the machine that died. Backups stored on the same server as the site protect against deletion and nothing else.
It is complete but unusable. Different PHP version, different database version, hardcoded paths from the old server. The data is all there and getting it running takes two days you did not have.
Nobody can restore it but one person. And they are on leave.
The test
Restore to somewhere that is not production. A staging site, a local environment, a temporary server. Then check three things:
- Does it load, log in, and show current data?
- How long did the whole restore take, measured honestly, including the parts where you had to look something up?
- Could somebody else have done it from the notes that exist?
That second number is your real recovery time. It is usually several times the estimate, and knowing it changes conversations about acceptable downtime.
Two numbers worth agreeing
How much data can you afford to lose? If backups run nightly, you are accepting up to a day of lost work. For a brochure site that is fine. For a store taking orders continuously it is not, and you need more frequent database backups than file backups.
How long can you afford to be down? This drives where backups live and how they are stored. Restoring from cold storage might take hours before the restore itself begins.
Most organisations have never stated either number, which means the answer is whatever the backup tool happened to default to.
Keep more than three days
Short retention is the most common weakness. Problems are frequently discovered long after they began: a corrupted import, a deletion nobody noticed, a compromise that sat quietly.
A sensible pattern is daily backups for a couple of weeks, weekly for a couple of months, and monthly for a year. Storage is inexpensive compared to the alternative.
Off the machine, and out of reach
At least one copy should be somewhere the live server cannot reach or delete. Ransomware specifically looks for connected backup locations, and a backup the compromised server can write to is a backup the attacker can destroy.
Write down the restore
Not the backup process. The restore. Where the files are, what the credentials are, what order things go in, what to check afterwards, and who to tell.
Write it so somebody who has never done it can follow it under pressure, and keep it somewhere that does not depend on the site being up. A document stored only on the server you are trying to restore is a joke that stops being funny at three in the morning.
How often to test
Twice a year is enough for most businesses. After any significant infrastructure change, do it again.
Put it in a calendar with a name against it. Restore testing is the definition of important and not urgent, which means it never happens unless it is scheduled.
It is part of our technical support work for exactly that reason: it is the task everyone agrees matters and nobody gets round to.
Further reading: the UK National Cyber Security Centre publishes practical guidance on backups, including why an offline copy matters and how often a backup restore should be rehearsed.
Related reading
- How to investigate an intermittent fault without guessing — Intermittent faults get fixed by accident and come back. A method for finding the real cause, and why changing several things at once never works.
- Remote or on-site support: what each is genuinely for — Most problems are solved faster remotely. Choosing remote or on-site support well saves both a wasted visit and a wasted afternoon. How to tell them apart.
- Handling patient-adjacent data in non-clinical systems — A booking form can hold healthcare data without anyone deciding it should. How to recognise it, where it ends up, and what changes once it is there.