“We have backups” is true right up until the day it is tested.
That day arrives when a site is broken by a change, compromised, or fails to come back after an update. Three questions then decide how much it costs: which day the backup restores to, how long restoring takes, and who knows how to do it.
For most people, that is the first time those questions get asked.
Two kinds of incident
They need different things.
Something broke. A template edited, a plugin installed, a configuration changed, and the site misbehaves. You know roughly when it happened and you need a few hours ago.
Something was done to you. A compromise, injected code, deleted data. You may not notice for days, and you need a point you are confident was clean — which also means being able to tell which day that was.
Daily backups kept for three days handle the first and cannot handle the second.
What a backup has to contain
Three parts, and missing one prevents recovery:
Files. Code, templates, images, uploaded documents.
The database. Content, pages, settings, users, orders. The critical one — files can be rebuilt, a lost database is genuinely lost.
Configuration. Server settings, DNS records, certificate setup, scheduled tasks. Most often omitted, because it does not live in the website directory.
Plenty of “automatic backups” cover only the first two, and the gap surfaces when restoring onto a new server takes hours of reconfiguration.
Retention: layered rather than maximal
Better than “daily, kept for seven days” is keeping several tiers:
Recent days: daily. For the “something broke” case, which is the common one.
Recent weeks: weekly. For “I think it was still fine last week”, which is how people actually remember.
Recent months: monthly. For problems that lay undiscovered for a long time.
The storage cost is small and the span covered is far longer. A week of retention leaves you helpless against anything planted a fortnight ago.
Where backups live
One rule: a backup cannot live only on the machine being backed up.
Obvious, and a great many sites keep their backups in a directory on the web server. When that server fails, is compromised, or is deleted by mistake, the backups go with it.
Compromise makes this vivid: anyone gaining access to a server usually deletes the backups first, precisely so that paying or accepting the loss are the only options.
So at least one copy belongs elsewhere — another provider’s storage, cloud storage, even a periodic download to a local machine. Different location matters more than more copies.
The step everyone skips: restoring once
The most important sentence here: a backup nobody has restored is not a backup.
The usual failures are all discovered at the worst moment:
Backup files are corrupt, generated faithfully and never opened. The database dump is incomplete, missing tables. The configuration inside no longer matches the current environment, so it restores and will not run. The archive is password-protected and nobody remembers the password. The procedure requires a step only the previous technician knew.
Every one of those surfaces only by actually restoring. Rehearse every six months: restore fully into a test environment and record how long it took. That duration is your real recovery capability.
Rollback is not backup
A backup returns you to a point in time. A rollback undoes a specific change, and should be faster and more precise.
With code in version control, rolling back is one command and returns you to just before a particular change without disturbing anything added since. Far better than restoring the whole site from a backup, which also reverses form submissions and articles published in the interim.
So prepare both separately: version control for code, backups for content and data. Most incidents originate in code or configuration, and anything solvable by rollback should not involve a backup at all.
In our own process, changes are syntax-checked before landing, key pages are verified automatically after installation, and all code is in version control. All three guards exist because something went wrong first.
Five questions for whoever maintains your site
Worth asking once, and the answers should be specific:
How often, and kept how long? “Regularly” is not an answer.
Stored where — the same machine as the site?
Does it include the database and server configuration?
When was a restore last actually tested? This one is most revealing.
If we had to restore now, how long until we are back? In hours.
Being unable to answer does not prove there is a problem, but it does show the question has not been considered. And backups have a particular property: no difference is visible on any ordinary day, and on the day it matters the difference is everything.
On the projects we host, backups are layered, stored off the server, and the restore procedure is documented. It is part of the service rather than something discussed after an incident.