The Backup You Have Never Tested Is Not a Backup

Five requirements

1. Files and database — both, or you have nothing
2. Automatic, on a schedule nobody has to remember
3. Off the server, so a server failure does not take the backups too
4. Retained for weeks, because problems are found late
5. Tested by actually restoring one

The fifth is the one nobody does and the only one that proves the other four. A backup you have never restored is a belief.

Why off-site matters

Backups stored on the same server are lost in exactly the scenario that matters most: server failure, compromise or account suspension.

Somewhere else — cloud storage, a different provider — is the whole point.

Retention answers the real problem

The common disaster is not a sudden failure. It is discovering three weeks later that something has been broken since a plugin update.

Daily backups retained for a week cannot fix that. A month of retention usually can.

What to check

• Does the backup include the database, not just files?
• Does it include uploads, or is the media library excluded to save space?
• How long are they kept?
• Where are they stored, and who can access them?
• How long does a restore take, in practice?

Restore once, to staging

Take the most recent backup, restore it to a staging site, and look at it. An hour of work, once, and you will know whether your backups are real.

The problems it finds — incomplete databases, missing uploads, broken permissions — are exactly the ones you do not want to discover during an incident.

Frequently asked questions