Website Backup Restore Done Right (And the Test Nobody Runs)
You have a backup. Whether it restores you to safety or restores you into a different disaster depends on things nobody checked when it was made. This is the restore in the right order, with the checks that turn it into a recovery.
The uncomfortable truths about backups, in the order they usually surface: most sites have never once tested a restore; many backups are partial — files without the database, or the reverse; some are months stale; and a large share sit on the same server as the site itself, so whatever killed the site takes the backups with it. A backup that has never been restored is a hope, not a plan. An emergency is a bad time to audit which kind you have — but it is usually when the audit happens anyway. Breathe first: most emergencies are recoverable, and the recoverable ones are lost to panic, not to the bug.
The restore done right starts before anything is overwritten. First, scope what is actually broken: a restore is a blunt instrument, and rolling back a week of orders and posts to undo one injured file is often the wrong trade — sometimes removing the injury beats reverting the world. When restore is right, the order matters: choose the correct point in time with the data-loss window stated honestly, pair files and database from the same moment (a new database under old files, or the reverse, is its own emergency), and preserve the current broken state before anything touches it — as evidence if the cause matters, as a fallback if the restore misfires.
Then comes the half nobody runs: verification. Restored is not the same as working. Logins, checkout, forms, email sending, scheduled tasks, the certificate — each gets exercised before anyone declares victory, because a restore that half-landed is worse than none: it feels fixed. After verification, two closing moves: the cause of needing a restore gets addressed so this is not monthly, and a tested-backup habit gets installed — off-server copies, known restore steps, and the test actually run. The maintenance retainer exists to keep both boring.
One warning that overrides everything: if a compromise is suspected, restoring a backup can re-import the malware that caused the emergency — backups from the infected period are contaminated, and the hacked-recovery track owns that sequence. For update injuries specifically, the broken-update page covers the targeted rollback that often beats a full restore. One senior developer, async-first, IST timezone; first response inside one business day — and no restore begins before the current state is preserved.
While you wait — the first 15 minutes
- Do not restore anything yet — first write down what is broken and when it started, because the restore decision depends on the injury, not the reflex
- Inventory your backups: who makes them (host? plugin? manual?), where they are stored, how old the newest is, and whether each includes the database as well as files
- Check where backups live — on the same server as the site is a single point of failure worth knowing about before you need it
- Preserve the current state before any overwrite: an export of the database and a file copy, even if broken — evidence and fallback in one step
- If anything suggests a hack — strange users, injected content, unfamiliar files — stop: restoring may reimport the infection; that track comes first
- Note the data-loss window you are prepared to accept (orders, posts, registrations since the backup) — the restore point is chosen against it
- Gather hosting, backup-account and admin access, then send the inventory — the restore plan follows what actually exists
These steps make every later fix cheaper. Do them in order, note what you changed, and include the notes in the brief.
What the engagement covers
Scope, stated plainly.
- Backup inventory and integrity assessment — what exists, what it contains, and whether any of it has ever been proven to restore
- Restore-point selection with the data-loss window stated plainly before anything is overwritten
- Files and database restored as a matched pair, in the safe order, with the current state preserved first
- Full functional verification after restore: admin, checkout, forms, email, scheduled tasks — exercised, not assumed
- The cause of the emergency addressed in writing, so the next restore is not already scheduled by fate
- A tested-backup setup: off-server copies, documented restore steps, and the test run for real
Honest limits
What to do instead.
A one-person senior practice is the right tool for a lot of emergencies and the wrong one for a few. The wrong ones, honestly:
- A successful-recovery guarantee when the only backups are corrupt, partial or absent — that limit is named before work starts, not discovered after
- Restoring onto a compromised server without cleanup — the hacked-recovery track owns that sequence; restore-after-clean, not restore-and-pray
- A 24/7 on-call promise — one senior, async-first, first response inside one business day
- Re-creating data that was entered after the newest backup — the loss window is stated and chosen, not conjured away
- Host-managed backup internals beyond what the provider exposes — their retention tools set some boundaries, honestly
After the emergency: stop the next one.
Every rescue ends with the same question — why was this able to happen? The maintenance retainer exists to make the answer boring: updates applied, backups tested, monitoring in place.
Questions
Asked in emergencies.
The only proof is a restore — which is why the test matters more than the backup. Short of a full drill, the checks that predict a lot: it includes both files and database, its age is measured in days not months, it lives somewhere other than the web server, and its size is plausible for the site. A professional audit replaces prediction with certainty — a restore rehearsed on a copy, so the real one is never the first.
Whatever was created after the chosen backup point is not in it — that is the data-loss window, and it is stated before the restore, not discovered after. Part of the scoping is recovering what can be recovered around the restore: exporting recent orders or content from the broken state before it is overwritten. The decision you get to make is the tradeoff, made visible.
Usually no — or at least not as the first move. Backups made during or after the compromise can contain the backdoor, and restoring reimports the intruder with a fresh timestamp. The hacked-recovery sequence is clean first, then rebuild from verified-clean sources. If the only clean backup is very old, that tradeoff is named honestly and the decision is yours, made with the real numbers.
Proportionally to how much the site changes: a busy store wants daily (or more) database backups with weekly files; a quiet brochure site can live on weekly. The non-negotiables matter more than the number: backups stored off the web server, both files and database, and a restore test on a schedule so the plan stays a plan. The maintenance retainer runs exactly this discipline so nobody has to remember it.
Other rescue work
WordPress Emergency Support
Your WordPress site is down, broken, or erroring and it cannot wait for the normal queue. Urgent work is slotted ahead of it — with an honest first response and realistic expectations.
WordPress Hacked Recovery
A hacked site is an incident, not a scramble. Recovery follows a standard sequence — isolate, backup, clean, patch, harden, rescan, monitor — with timelines scoped for realism, not false promises.
Website Takeover — When Your Developer Disappears
Your developer vanished, or the relationship ended badly, and you are locked out of your own website. This rescue recovers access, audits what you actually own, and takes the site back — properly.
WordPress White Screen of Death — Diagnosis and Rescue
The page is blank, the admin may be gone with it, and nothing tells you why. The white screen is almost never mysterious — it is a PHP fatal error hiding in plain sight, and it has a specific, findable cause.
"Error Establishing a Database Connection" — Rescue
That single error line means WordPress reached your server but could not open its database — a dead end with roughly four known doors. Finding which door is the whole job, and each has a different fix.
WordPress Emails Not Sending or Landing in Spam
Contact forms that never arrive, order confirmations in the spam folder, password resets that vanish. WordPress mail failure is an infrastructure problem wearing a plugin costume — and the fix lives at the email layer, not in the form.