Backups You Have Never Tested Are Not Backups

Ask a business owner whether they have website backups and the answer is almost always yes. Ask when they last restored one and the room gets quiet.

That gap is not pedantry. A backup is a claim; a restore is a fact. Until you've done the second, you have a claim.

The ways backups fail quietly

They're on the same machine. A backup stored on the server it's backing up covers exactly one failure mode — you deleted something — and none of the others: the server dies, the account is suspended, the host has an incident, ransomware encrypts the volume.

They only cover files, or only the database. A WordPress site is both. Restore one without the other and you have a working site full of missing content, or content with nowhere to live.

They're too shallow. Seven days of retention sounds reasonable until you discover a corruption that started three weeks ago. Something monthly, kept for a year, costs almost nothing and has saved more than one client.

They silently stopped. The plugin was deactivated during an update. The destination's credentials expired. The disk filled. Nobody was told, because failure notifications go to an address nobody reads.

They contain the problem. If a compromise happened before your oldest backup, every restore point includes the backdoor.

What a real backup policy looks like

The old rule still holds: three copies, two kinds of storage, one of them somewhere else. For a website that usually means the live site, an automated backup on the host, and an off-site copy in independent storage.

Add to that:

• Automated, not remembered. Anything requiring a human to think about it monthly will lapse within a year.
• Monitored. A successful backup should be as noisy as a failed one — or at least, a failure must reach a person.
• Retained on a schedule you chose deliberately. Daily for a fortnight, weekly for a quarter, monthly for a year is a sane default.
• Encrypted, if it contains customer data, which it does.

The test

Once a quarter, restore to somewhere that isn't production — a staging site, a local environment, anywhere.

Then check the things nobody checks: does the site load, are the images there, does the database include last week's content, do the forms work, is the plugin configuration intact?

Time it. "We can be back within two hours" is a very different conversation with an anxious client than "we think we have backups somewhere."

The two numbers worth agreeing on

How much data can you afford to lose? That sets backup frequency. A brochure site can lose a day; a store taking orders cannot lose an hour.

How long can you afford to be down? That sets what you need standing by. If the answer is "an hour," a nightly archive in cold storage isn't enough on its own.

Most businesses have never been asked either question, and both turn out to be surprisingly easy to answer once someone does.