How to Verify a WordPress Backup Before You Need to Restore It

Your backup plugin says “Backup completed successfully.” That green message is reassuring, but it only proves one thing: a file was written somewhere. It does not prove the archive is complete, that the database dump captured every table, or that you could actually bring your site back after a bad update, a hack or a server failure. This guide shows you how to verify a WordPress backup before you ever need to restore it, using simple checks that take minutes rather than hours.

Why a “successful” backup can still fail you

Most backup failures are silent. The job finishes, the log looks fine, and nobody notices a problem until the day a restore is needed. The most common causes are:

• Truncated archives: the job times out halfway through a large uploads folder, but a partial zip is still saved.
• Database-only backups: some plugins default to backing up only the database, so themes, plugins and media are missing.
• Expired remote credentials: the local copy works, but the upload to cloud storage quietly stopped months ago.
• Corruption in transit: a file damaged during download or transfer looks normal until you try to unzip it.
• Retention gaps: old, good copies get rotated out, leaving only backups taken after a problem started.

The fix is not a fancier backup tool on its own. It is a habit of verifying backups regularly, ideally with checks that run automatically.

Step 1: Confirm what your backup actually contains

Open your backup settings and check the scope. A complete WordPress backup should include:

• The full database (posts, pages, users, settings, orders)
• The wp-content folder: themes, plugins and uploads
• Your wp-config.php file or a note of its settings
• Any custom files such as .htaccess rules or must-use plugins

If any of these are missing, you are backing up part of your site, not all of it.

Step 2: Check archive integrity with checksums

A checksum is a short fingerprint of a file. If even one byte changes, the fingerprint changes. Comparing the checksum recorded at backup time with the checksum of the file you have now tells you instantly whether the archive is intact.

If you have shell access, you can test a zip with unzip -t backup.zip or a gzip database dump with gzip -t backup.sql.gz. Better still, use a backup plugin that records SHA-256 checksums in a manifest and verifies them before every restore. Our Backup Restore Verifier Pro plugin does exactly this: each backup is a single zip with a manifest, and a damaged or tampered archive is rejected instead of being half-applied to your live site.

Step 3: Compare key numbers against your live site

A quick sanity check is to compare a few counts between your live site and the backup. If you use WP-CLI, run these on both:

• wp post list --post_status=publish --format=count for published content
• wp user list --format=count for users
• wp plugin list --status=active --field=name for active plugins

Also count files in the uploads folder. If your live site has 9,000 media files and the backup has 6,000, the archive is incomplete. Check the date of the newest post in the backup too: if it is three weeks old, your scheduled backups may have been failing for three weeks.

Step 4: Do a real test restore on staging

The only complete proof is a restore. Never test by restoring over your live site. Instead, restore into a staging copy, a subdomain or a local install with a similar PHP and MySQL version. Then check:

• You can log in to wp-admin with your normal account
• Pages, posts, menus and images all load correctly
• Plugins are active and the theme looks right
• Forms submit, search works and, for stores, checkout loads

Before you start, disable outgoing email, payment webhooks and search indexing on the staging copy so customers do not receive test messages and Google does not index a duplicate site.

Write down how long it took

Time the whole process from “I need to restore” to “the site works.” That number is your real recovery time. If it is far longer than you expected, now is the time to simplify the process, not during an emergency.

Step 5: Automate verification so you do not forget

Manual checks are easy to skip when you are busy. Set up a routine that does most of the work for you:

• Schedule daily database backups and weekly full backups.
• Send copies to at least one off-site destination you own, such as S3, Backblaze B2 or Google Drive.
• Take an automatic backup before plugin, theme and core updates.
• Use checksum verification before every restore.
• Run a full staging restore test at least once a quarter.

Pair your backups with good security and performance habits. A site that is scanned for malware with a tool like our Security Scanner and Firewall Suite is far less likely to need an emergency restore in the first place.

A simple backup verification checklist

• Backup scope includes database, wp-content and configuration
• Archive passes an integrity or checksum test
• Post, user, plugin and media counts match the live site
• Newest content in the backup is recent
• At least one copy is stored off-site
• A staging restore has been tested in the last 90 days
• Recovery time is written down

Want someone to handle it for you?

If you would rather not run restore drills yourself, our team can set up verified backups, managed hosting and ongoing maintenance for your site. See our WordPress services, or browse all of our plugins and themes in the 007AJ shop.

Frequently asked questions

How often should I test a WordPress backup?

Run an integrity or checksum check on every backup, ideally automatically, and do a full test restore on a staging site at least once every three months, plus after any major change to your hosting or site.

Can I verify a backup without restoring it?

Partly. Checksums and archive tests confirm the file is intact, and comparing counts confirms it looks complete. Only a real restore on staging proves the site will actually work afterwards.

Is my host’s backup enough?

Host backups are useful, but they are usually stored on the same provider. Keep at least one independent copy in storage you control, so a billing problem or account issue with your host cannot take your backups with it.

What is a SHA-256 checksum?

It is a unique fingerprint calculated from a file’s contents. If the file changes or is damaged, the checksum no longer matches, which tells you the backup should not be trusted.