Backups are the only maintenance task whose failure you discover, by definition, too late. Everything else fails forward — a bad update breaks the site today, downtime alerts today. A backup fails in the past: quietly, months ago, and you find out at the exact moment it was supposed to save you. That asymmetry is why backup strategy isn’t a plugin choice. It’s a handful of principles that decide whether your worst day is a bad hour or a lost business.
3-2-1, translated to WordPress.
The old sysadmin rule still carries the weight: three copies, two kinds of storage, one offsite. For a WordPress site, concretely:
- 01Three copies. The live site, a primary backup, and a second backup somewhere else. Two is the minimum that survives one failure; three survives the failure you discover late.
- 02Two kinds of storage. Not two folders on the same disk. Host storage plus object storage (S3, R2, B2), or host plus a machine you control. Different failure modes are the entire point.
- 03One offsite. At least one copy must live outside your hosting company entirely — different provider, different account, different credentials. Hosting accounts get suspended, compromised and billing-expired; your backup must not share their fate.
Back up the files and the database.
A WordPress site is two things. The files: theme, plugins, uploads, custom code. The database: every post, page, order, user and setting. Backing up only one produces a half-backup that restores to a broken site — and file-only backups are the classic mistake, where the uploads folder survives but five years of content doesn’t.
The database is also where naive backups corrupt. WordPress stores serialized PHP arrays whose byte-lengths must match exactly — a careless export or charset mismatch breaks them silently. Plugins keep binary data in BLOB columns that text-mode exports mangle. Emoji and legacy latin-1 content cross character sets badly. A dump can finish without a single error and still contain wrong bytes; you find out at restore time. Or after.
Retention: two days is a trap.
“Daily backups” with two days of retention sounds fine until you consider how problems are actually found. Malware is routinely discovered weeks after infection. A corrupted table can hide behind a cache for a month. If your retention is shorter than your detection time, every backup you hold is a faithful copy of the problem.
Thirty days is the sane default: long enough that “we found it late” still has a clean restore point behind it, short enough to store cheaply. If storage is tight, keep a weekly copy for longer rather than shrinking the window.
Offsite and encrypted, or it doesn’t count.
A backup on the same server dies with the server — same disk failure, same ransomware, same account suspension. Many backup plugins default to writing into wp-content, which means the most common backup configuration in the wild protects against almost nothing that matters. Ship copies off the box, to storage your host can’t touch.
And encrypt them. A backup is your entire site in one convenient file — every user record, every order, every password hash. Sitting unencrypted in a misconfigured bucket, it isn’t a safety net; it’s a breach with a timestamp.
A backup is a hypothesis. A restore is proof.
Everything above — 3-2-1, retention, offsite — is arranging hypotheses neatly. None of it tells you whether the file actually turns back into a working website. The only thing that does is restoring it. The drill, quarterly at minimum and monthly if the site earns money:
- 01Spin up an isolated environment — a local install or a scratch subdomain from your host. Never drill on production.
- 02Restore the most recent backup end to end, files and database, using your tool's actual restore path — the same one you would use at 2am.
- 03Click through like a customer: log in, open the key pages, run a search, submit a form, and on a store, open a recent order.
- 04Compare against the live site. Recent content present? Media loading? Special characters and emoji intact? Note how long the drill took — that is your real recovery time, measured while calm. Double it for panic.
If any step fails, your backup strategy was a story you were telling yourself — and better to learn that during a drill than during an outage. Put it on your monthly maintenance checklist next to the tasks that merely feel productive.
Six ways backups rot silently.
We ran a full data-fidelity audit of our own backup and restore pipeline and found six distinct bugs — every one producing backups that looked valid and restored wrong. We fixed them and turned each into a permanent automated check; the full write-up is on the data safety page. The list is worth knowing whatever tool you use:
- 01Percent-signs and URLs corrupted by WordPress's own escaping layer
- 02Binary and BLOB data mangled in JSON transport
- 03Latin-1 characters lost on legacy sites
- 04SQL comments inside real content stripped on restore
- 05Real customer tables mistaken for cache tables — and skipped
- 06Zero-byte files silently dropped from file backups
Every one of these survives “backup completed successfully.” Only byte-level verification and real restore drills catch them — which is the uncomfortable takeaway of this entire guide.
The same principles, automated.
For completeness, our production setup: daily encrypted backups (Standard plans and up) shipped offsite to a private Cloudflare R2 bucket, 30-day retention with one-click restore from any day. Every backup is verified byte-for-byte at capture — truncated or empty dumps are rejected loudly, never uploaded and forgotten. Weekly restore drills into an isolated scratch database with a corruption scan do the proving on our schedule, not during your outage. And every update runs against a fresh restore point. Details on the backups page.