Five requirements
- Files and database — both, or you have nothing
- Automatic, on a schedule nobody has to remember
- Off the server, so a server failure does not take the backups too
- Retained for weeks, because problems are found late
- 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.