Backups That Survive Real Disasters: The 3-2-1 Rule for WordPress

Most WordPress backup failures are not caused by missing backups. They are caused by backups nobody ever tried to restore. A corrupted archive, a missing table, a database dump that references a file path that no longer exists, all of these hide quietly until the night you actually need them. The fix is not a fancier plugin. It is a disciplined scheme, and a drill you run on a schedule.

What 3-2-1 actually means

The 3-2-1 rule is old advice from general IT backup practice, and it maps cleanly onto WordPress:

• 3 copies of your data: the live site, plus two backups.
• 2 different media or locations: for example, your host’s storage and a separate cloud provider. Never keep both backups on the same server as the live site.
• 1 copy off-site, meaning physically and logically separate from your hosting account. If your host account is compromised or your server disappears, this copy survives.

The part people skip is the off-site copy. A backup stored in the same hosting account as the site it protects is not really a backup. It is a second file that can be deleted, encrypted by ransomware, or lost in the same outage as the original.

What a WordPress backup actually needs to contain

A WordPress site is two things bolted together: files and a database. Both matter, and they need to stay in sync.

• The database: posts, pages, options, users, and (critically) plugin and theme settings that live in the wp_options table.
• wp-content: themes, plugins, and uploads. Uploads especially, since they cannot be regenerated from anything.
• wp-config.php (excluding secrets you would rotate on restore, like database credentials, which will differ on a new host).
• .htaccess or server-level rewrite rules, if you rely on them for redirects or security rules.

You do not need to back up core WordPress files themselves; those can be re-downloaded. Focus your storage and bandwidth on what is actually irreplaceable.

A quick database dump with wp-cli

If you want to script backups yourself, wp-cli makes the database half straightforward:

wp db export backup-$(date +%F).sql --add-drop-table

Pair that with a compressed archive of wp-content:

tar -czf wp-content-$(date +%F).tar.gz wp-content/

For anything beyond a single small site, a dedicated backup plugin or your host’s built-in backup system will handle scheduling, incremental transfers, and off-site delivery more reliably than a cron job you wrote once and forgot about. The wp-cli commands above are useful for one-off snapshots before a risky change, or for verifying what a backup plugin actually captured.

Versioning: keep more than one point in time

A single backup only protects you from total loss. It does not protect you from a bad update that silently corrupts content, or a hack that sits dormant for two weeks before it is discovered. If your only backup is from last night, and the compromise happened ten days ago, you will restore a compromised site.

Keep a rolling window of versions, not just the latest one. A reasonable baseline for most sites:

• Daily backups retained for 7 to 14 days.
• Weekly backups retained for 4 to 8 weeks.
• A monthly backup retained for 6 to 12 months, especially for sites with legal, financial, or compliance history worth preserving.

This costs more storage than keeping only the latest copy, but storage is cheap compared to the cost of not having a clean version to restore.

Encryption: your backups are a target too

A backup archive is often a more attractive target than the live site. It contains your full database, including password hashes, API keys, and user data, all in one portable file. If that file sits unencrypted in a cloud storage bucket with a guessable name, it is a liability.

At minimum:

• Encrypt backup archives at rest, either through your backup tool’s built-in encryption or by encrypting the archive yourself before upload.
• Use unique, non-obvious storage paths or bucket names rather than something like yoursite-backups.
• Restrict access credentials for your backup storage to the minimum needed, and rotate them if a team member with access leaves.

Where off-site actually means off-site

Off-site does not mean a different folder on the same server. It means a separate provider and, ideally, a separate account boundary. Common patterns that satisfy this:

• Your host’s storage plus a cloud object store (S3-compatible storage, Backblaze B2, Google Cloud Storage, and similar) under a separate login.
• Your host’s storage plus a different backup plugin that pushes to a different destination, so a single plugin bug or account compromise cannot wipe both copies.
• For agencies managing several client sites, a centralized backup destination that is not tied to any single client’s hosting account.

If your host offers automated off-site backups as part of the plan (this is one of the things a managed host like ServerBorn handles for you by default), that satisfies the off-site leg without extra setup, but it is still worth keeping a second independent copy for anything business-critical.

The restore drill: the step almost nobody does

Here is the uncomfortable truth: most site owners have never actually restored from their backups. They have confirmed backups exist, maybe even downloaded one, but never gone through a full restore to a working site. That is the equivalent of buying a fire extinguisher and never checking if it’s charged.

Run a restore drill on a schedule, at least quarterly, more often for high-traffic or revenue-generating sites:

1. Spin up a staging environment or a throwaway subdomain separate from production.
2. Restore your most recent backup there, files and database both.
3. Verify the site loads, log in as an admin, and check that key pages, forms, and any e-commerce functionality actually work.
4. Confirm the database import didn’t silently fail on a table, and that uploads are present, not just referenced.
5. Time the whole process. Know how long a real restore takes, so you’re not guessing during an actual incident.
6. Document what you did, in plain steps, so someone else on your team (or a future you, at 3 a.m., under pressure) can follow it without reverse-engineering your setup.

If any step fails, you have just found a broken backup while it costs you nothing, instead of finding it during a real disaster when it costs you everything.

Takeaway

Backups are not a checkbox, they are a system: three copies, two locations, one of them off-site, versioned across a rolling window, encrypted at rest, and tested by an actual restore on a real schedule. The plugin or provider you use matters less than the discipline of verifying it works. Do the drill before you need it, not during.