A Backup Is Not a Restore Test
Why a green backup status does not prove that your website can actually recover after an outage.
A green check mark in a backup dashboard feels reassuring. Unfortunately, it does not prove that you can actually recover your website after an outage.
Backups rarely fail in a spectacular way. More often, they are incomplete, too old, encrypted with a key nobody can find, or dependent on the same system that has just failed. The gap becomes visible under pressure: after a broken deployment, a compromised server, or database corruption.
The uncomfortable difference between backup and recovery
A backup is a stored copy. A restore is a working process.
To recover a website, application code, databases, uploads, configuration, secrets, DNS dependencies, and documentation all need to work together. A database dump alone is not enough for WordPress, just as a container image without persistent data and environment configuration is not enough for a SaaS product.
CISA recommends testing backups regularly and keeping at least one copy separate from the production network. NIST contingency-planning guidance likewise treats recovery as a documented and tested capability, not merely a storage feature.
Quick check: could you be back online today?
Try answering these questions without searching for the one person who “set it up years ago”:
- Do you know when the last successful restore was tested?
- Is there a copy outside the production hosting account?
- Are database, files, and configuration from a consistent point in time?
- Are encryption keys and credentials documented separately?
- Can you restore into a fresh server or account?
- Is it clear who makes decisions and communicates during an incident?
- After restoration, are login, forms, payments, email, and uploads tested?
Several “no” answers do not automatically mean your website is unsafe. They do mean your backup setup has not yet demonstrated that it works.
A practical restore test
A useful test does not need to start as a full disaster exercise.
- Restore the website into an isolated test environment.
- Follow documented steps rather than one person’s memory.
- Verify migrations, media, scheduled jobs, external storage, and secrets.
- Test the most important user journeys.
- Measure the recovery time.
- Document failures and repeat the test after fixes.
That final step matters. A failed restore test is not embarrassing; it is an inexpensive discovery, provided it does not happen during a real incident.
What Website-Pflichtencheck would review
A technical website review should not stop at confirming that a backup switch is enabled. It should assess retention, separation from production, coverage of required data, permissions, documentation, and evidence that a restore has been tested.
This is especially valuable after a relaunch, hosting migration, agency change, or major architecture update. Old backup jobs sometimes continue running while reliably protecting the wrong system.
A backup that has never been restored is hope with a timestamp. If you cannot explain how your website would come back on a clean environment, review the recovery process before an incident becomes the first rehearsal.