Why Your WordPress Backup Isn’t a Real Backup

A Fair Lawn nonprofit called us in panic last August. A bad plugin update had broken their site and corrupted three of their database tables. Their host's "dail
Why Your WordPress Backup Isn't A Real Backup

A Fair Lawn nonprofit called us in panic last August. A bad plugin update had broken their site and corrupted three of their database tables. Their host’s “daily backup” was sitting right there in cPanel. The restore failed. The August 4 backup, the August 3 backup, and the August 2 backup all failed the same way. The corruption had been silently overwriting backups for five days before anyone noticed. Restore time to a clean state: 11 hours and $2,400 of recovery work.

They had a “backup.” They did not have a backup. The difference cost them a full business day and a hard look from their board.

Why your daily host backup is a single point of failure

Your host’s nightly backup almost always lives on the same physical disk array as your site. Sometimes the same server. Sometimes a sibling drive in the same rack. If the disk fails, the site and the backup go down together. If the server is compromised, the attacker often deletes or encrypts the backups before you notice anything is wrong (this is the standard ransomware playbook in 2025).

Even when the storage is “separate,” it is usually the same provider’s data center. One billing dispute, one hacked account, one host going under, and the backup goes with the original.

The 3-2-1 rule, in plain English

  • 3 copies of your data. The live site, plus two backups. Two is not redundant — one of them will fail when you need it.
  • 2 different storage types. Not “two copies on the same disk array.” One on the host. One on a different medium, ideally a different provider.
  • 1 copy off-site. Different physical location, different cloud account, different vendor. The off-site copy is the one that survives a ransomware event, a host bankruptcy, or a billing-account lockout.

This is the rule the IT industry has used for 40 years. WordPress site owners almost universally skip steps 2 and 3.

The test that proves a backup is real

A backup that has never been restored is not a backup. It is a hope. The only proof is a successful restore to a clean environment.

Spin up a staging environment (most managed hosts give you one free, or use a local Docker WordPress in 10 minutes). Download your most recent backup. Restore it. Log in, walk five real pages, submit the contact form, check the database for your most recent post. If any step fails, the backup is broken. In our experience, 9 out of 10 site owners who run this test the first time discover their backups are partially or fully unusable.

The four ways backups quietly fail

  • Truncated dumps. The backup process hits a memory limit and writes a partial SQL file. The job logs “success” because the script returned 0.
  • Stale uploads. The plugin backs up the database nightly but only does files weekly. You restore, half your media is gone.
  • Same-disk syndrome. Everything is fine until the disk dies and the backup dies with it.
  • Forgotten exclusions. Someone added `wp-content/uploads/2023` to the exclude list three years ago to save space, and nobody has reviewed the config since.

What a real backup costs

A proper 3-2-1 setup for a typical WordPress business site costs $5-15/month. BackupBuddy, UpdraftPlus Premium, or Solid Backups, configured to push to two destinations (Amazon S3 plus Google Drive, or Backblaze B2 plus Dropbox), runs around $7/month including storage. The off-site monthly snapshot test takes 20 minutes if you script it.

$84 a year versus a $2,400 emergency recovery, plus the revenue lost during the 11 hours your site was down.

How AJD handles this

Every site on our maintenance plan runs 3-2-1 by default. One copy on the host. One copy in our managed Backblaze B2 bucket. One copy in a Wasabi off-site account that is on a different billing entity entirely (so a hijacked AJD account cannot wipe client backups). The third copy is restored to a staging environment automatically every Sunday morning, and a smoke-test script confirms the site boots and the database loads. If any check fails, we get an alert before the client does. We have triggered a real restore from this system 7 times in the last 18 months. Average time to fully recovered site: 38 minutes.


Whether you work with us or not, run the restore test this week. Pick your most recent backup, spin up a staging environment, and try to bring it back. If it does not restore cleanly, you have a problem that is silent until it is catastrophic. Fix it now, while the site is healthy.

Book Free 15-Minute Discovery Call — we will audit your current backup setup live, identify the gaps against the 3-2-1 rule, and show you the cheapest path to a real backup. No upsell.

Book Free Discovery Call →

Table of Contents

AJD Digital Solutions

Need a clearer digital plan?

Improve your website, visibility, content, and analytics with a practical next step from AJD.

Subscribe

Get practical digital growth notes.

Receive occasional AJD insights on websites, SEO, local visibility, content, and analytics. Useful guidance only — no noise.

No spam. Unsubscribe anytime.

Book Free Discovery Call