Back to Blog

Engineering

Verified Backups: Why Testing Your Backups Matters More Than Making Them

Sascha Endlicher · March 5, 2026 · 8 min read

Every agency and freelancer managing WordPress sites knows the drill: set up a backup plugin, configure a schedule, maybe store copies in an S3 bucket, and move on. The backups run, the dashboard shows green checkmarks, and everyone sleeps well at night.

Until the day you actually need to restore one.

That is when you discover the backup is corrupted, the database dump is incomplete, or the file archive is missing critical wp-content assets. The green checkmark was a lie. The backup process completed without errors, but the resulting artifact was never actually tested.

The silent failure problem

In infrastructure engineering, there is a well-known principle: an untested backup is not a backup. It is a hope. Yet the entire WordPress ecosystem treats backups as a "set and forget" operation. The dominant backup plugins focus exclusively on the creation side — scheduling, compression, remote storage — while completely ignoring verification.

We analyzed backup failure patterns across hundreds of WordPress sites and found three primary failure modes:

  • 1. Database corruption — MySQL dumps that silently truncate large tables, especially on shared hosting with memory limits.
  • 2. Incomplete file archives — Tar or zip operations that skip files due to permission errors or symlink issues without reporting failure.
  • 3. Storage-layer failures — S3 multipart uploads that partially succeed, leaving behind objects that look complete but cannot be downloaded intact.

"An untested backup is not a backup. It is a hope. And hope is not a strategy for disaster recovery."

How verified backups work

BlockForge takes a fundamentally different approach. After every backup is created and stored, we spin up an isolated Docker container, load the backup into it, and run a series of automated checks to verify the backup is actually restorable.

The verification pipeline runs through four stages: 

Stage 1: Archive Integrity
  - Verify checksum matches stored hash
  - Extract archive, confirm all files present
  - Validate file count against manifest

Stage 2: Database Verification
  - Import SQL dump into fresh MySQL instance
  - Verify all tables exist and row counts match
  - Run WordPress table structure validation

Stage 3: Application Boot
  - Start PHP-FPM + Nginx in container
  - Load WordPress with backup data
  - Confirm wp-admin dashboard renders (HTTP 200)

Stage 4: Content Verification
  - Crawl homepage and 5 random pages
  - Verify HTTP 200 responses
  - Check for PHP fatal errors in output

Only after all four stages pass does the backup receive a "verified" status. If any stage fails, the backup is flagged, and an alert is sent immediately.

The container architecture

Each verification runs in a completely isolated environment. We use lightweight Docker containers with a pre-built WordPress runtime image that includes PHP, Nginx, and MySQL. The container boots in under 10 seconds, imports the backup, runs all checks, and tears down. 

$ blockforge backup:verify --site=agency-portfolio.com --backup=2026-03-05

[1/4] Archive integrity ............ PASS (sha256 match)
[2/4] Database verification ........ PASS (42 tables, 128,491 rows)
[3/4] Application boot ............. PASS (wp-admin: 200 OK, 1.2s)
[4/4] Content verification ......... PASS (6/6 pages: 200 OK)

Backup verified successfully.
Duration: 47s | Container: bf-verify-a3f8c2

The entire process is stateless and reproducible. No data persists after verification. The container is destroyed, and only the verification result is stored alongside the backup metadata.

Why this matters for agencies

If you are managing 20, 50, or 100+ WordPress sites for clients, backup reliability is not just a technical concern — it is a business risk. A single failed restoration can cost hours of emergency work, damage client trust, and in some cases, result in permanent data loss.

With verified backups, you know with certainty that every backup in your system is restorable. The verification runs automatically after every backup, and the results are visible in your dashboard. No manual testing required. No uncertainty.

For client reporting, each backup includes a verification timestamp and status that can be included in monthly reports — giving your clients concrete proof that their data is protected.

"The best backup is the one you never need. The second best is the one you know works."

Getting started

Verified backups are available on all BlockForge plans. Once you connect a site, backups are created on your configured schedule and automatically verified. No additional configuration is needed.

You can view the verification status of every backup in the site dashboard under Backups → Verification History. Failed verifications trigger immediate alerts via your configured notification channels (email, Slack, or both).

SE

Sascha Endlicher

Founder & CEO at BlockForge

Related posts