Verify A WordPress Backup, Or You Only Have A File With A Hopeful Name.

Short answer: to verify wordpress backup files you have to restore them. Into a scratch database, then count the rows and compare with live. Everything short of that, including the plugin reporting success and a file appearing with today’s date, tells you a file was written. It does not tell you the file works.

I proved this to myself this week rather than repeating it as received wisdom.

Two files, one useless

I took a complete backup of a WordPress database, then made a second copy truncated mid-write, which is what happens when a disk fills, a process is killed, or a connection drops.

Then I restored both.

eight tables out of seventy-seven, and wp_posts was not among them.*

Nothing about the broken file announces itself. Right name, plausible size, correct folder, today’s date. Every check most agencies run would have passed it.

The only check that failed it was restoring it.

How to verify a WordPress backup, in under a second

touched, because the restore goes into a database created for the purpose and dropped afterwards.*

Two rules for doing this safely, and the first one is not negotiable.

Never restore into the live database to test a backup. Create a scratch one. A verification step that can destroy the thing it is verifying is not a verification step.

Compare row counts, not just success. A restore can complete without error and still be missing content if the dump was taken while a table was locked. wp_posts, wp_options and wp_users counts against live is enough to catch it.

What each check is actually worth

entirely: plenty of setups back up the database faithfully and never touch wp-content, so uploads, themes and plugins are not in the backup at all.*

It is also worth confirming the backup is stored somewhere the site cannot reach. A backup sitting in wp-content on the same server is not a backup, it is a second copy of the thing that is going to break, and it is downloadable by anyone who guesses the filename.

That last one is worth a specific check on any site you inherited. Take the backup, look inside it, and confirm wp-content/uploads is actually there. A database-only backup cannot rebuild a site, and the day you discover that is the worst possible day to discover it.

Why this is the check that never gets done

It is not difficult and it is not slow. It is that a verified backup and an unverified one look identical right up until the moment one of them matters.

There is nothing to show a client. No line on an invoice. No visible improvement to the site. So it loses to work that produces something, every single week, on every site.

It is the unbilled half hour in its purest form: cheap, invisible, and the only thing standing between a bad update and a lost client.

And it compounds with the other silent failures. If the scheduler on the site has stopped, your scheduled backups have not been running at all, and the most recent file in that folder may be from March.

This is why the update playbooks in Protuno prove a backup restores before anything writes to a site, rather than simply taking one first. Taking a backup and having a backup are different things. Straight with you as on every post here: Wren, the Care agent that runs those playbooks, is built and named but not live yet.

Do the manual version this week on one client site. Take the backup, restore it into a scratch database, count the posts. If the number matches, you have learned something real. If it does not, you have just avoided a very bad afternoon.