How to test a backup, because an untested backup is a wish
A backup proves itself only when it restores. The quarterly test: what to restore, where, how to check it, how long it took, and what to write down.
The short answer
A backup exists to bring the site back. The only way to know whether it can is to bring the site back from it, somewhere safe, and use the result. Everything else, a green tick in a dashboard, a file with a recent date, a provider’s promise, is evidence that a process ran, not that it produced something usable. The test takes an hour a quarter, and the first one nearly always finds something.
The quarterly test
- Pick the backup. The most recent, or a random older one to test retention.
- Restore it to a separate place. A staging project, a preview environment, a temporary server. Never over live.
- Use it. Log in. Open the most recent article, order or record. Open an image uploaded last week. Submit a test form if functions are part of the site. Check the settings that matter.
- Check the surroundings. Do you also have the DNS records, the configuration, the secrets and API keys, and the documentation to go with the restored site? A site without its keys does not talk to anything.
- Time it. From starting to a usable site. That number is your real recovery time.
- Write one line. Date, which backup, what was missing, how long it took, what was fixed.
What the first test usually finds
| Missing | Why | Fix |
|---|---|---|
| Uploaded files | The backup covered the database and code, not the media folder | Add uploads to the backup set |
| Configuration and secrets | Environment settings live in the hosting dashboard, not in the backup | Export them to the password manager; document them |
| DNS records | Nobody thought of DNS as part of the site | Export records with every backup |
| Recent data | The backup ran before yesterday’s orders | Increase frequency for the database |
| Old restore points | Only last night exists; the problem started last month | Add retention: weeks of dailies, months of weeklies |
| A working restore procedure | Nobody had done it before, so it took a day | Write the steps down during the test |
Making it routine
Put it in the calendar every quarter, assign it to a named person, and keep the one-line log with your documentation. On a modern static setup the test is fast: restore the repository and content, deploy to a preview, check. On a plugin-based platform it takes longer, which is one more argument for the modern setup.
What this means for you
Ask whoever runs your site when a backup was last restored and how long it took. If the answer is a date and a number of minutes, you have a recovery plan. If the answer is “the backups run every night”, you have a wish, and the quarterly test is how you turn it into a plan.
Frequently asked questions
Our hosting says backups run daily. Isn't that enough?
Running is not restoring. Provider backups are a good first layer, but until you have restored one to a separate place and used the result, you do not know what is in it, what is missing, or how long it takes. The test answers all three.
Where do we restore to?
A separate, private location: a staging project on the hosting platform, a preview environment, or a temporary server. Never over the live site. The point is to prove the backup works without risking anything.
What if the test fails?
Then you have found out on a Tuesday in a test instead of on a Saturday after an incident. Fix what was missing, add it to the backup, and test again. A failed test is the backup process working as intended.