Website backups that actually restore

A backup you’ve never restored is a hope, not a backup. The only proof a backup works is a completed restore — done calmly, on purpose, before the day you need it done frantically.

What a complete website backup contains

Three things, and missing any one makes the set incomplete: the database (your content, users, orders), the files (uploaded images and documents, which usually live outside the database), and the code (the theme and customizations that make your site yours). Lots of “we have backups” situations turn out to be one of the three — usually the database alone, which restores into a site with every image missing.

The 3-2-1 rule, sized for a website

Three copies of your data, on two different systems, one of them somewhere else entirely. In practice: the live site, your host’s automatic backups, and a copy that leaves the host — because if the hosting account itself is the thing that fails (billing lapse, account takeover, a provider dispute), backups stored inside it fail with it. The off-host copy is the one that has saved every rescue it’s been present for.

The one test worth scheduling

Twice a year, restore a backup somewhere harmless — a staging copy, a local environment — and click around. You’re checking three things: the restore completes, the result is current (a backup job that silently died eight months ago looks identical to a working one in the dashboard), and the result is whole — images load, content is there, you can log in.

Ten minutes, twice a year. It’s checking the canoe for cracks in May instead of mid-lake in July.

If you don’t know where your backups live — or whether they exist — that’s one of the four keys in who actually owns your website, and finding out is a fine reason to spend an afternoon.