Backup Testing and Verification: Prove it works

A backup you've never tested is not a backup. It might be corrupted, incomplete, unreadable, or inaccessible when you need it most. Testing proves your backups work before disaster strikes.

Why test backups?

Untested backups can fail for many reasons:

• Corruption: Backup file is damaged or truncated
• Incomplete data: Some files or tables weren't backed up
• Format incompatibility: Backup was created with old software; can't be restored with new versions
• Forgotten passwords: Encryption passphrase lost or wrong
• Missing dependencies: Backup has the website but not the database, or vice versa
• Storage failure: Backup storage provider lost data
• Inaccessibility: Backup exists but you can't download or access it
• Restore procedure forgotten: You don't remember how to restore from your backup

Testing catches these problems while there's time to fix them—not during an emergency.

The backup testing myth

Myth: "I have backups, so I'm protected."

Reality: You're only protected if:

• Backups are actually created (not skipped due to errors)
• Backups contain all your data (files AND database)
• Backups are intact and not corrupted
• Backups are accessible (not lost or inaccessible)
• You can restore them (know the process, have tools, have passwords)
• Restored data actually works (not corrupted, compatible with your setup)

Testing verifies all of this. Without testing, you're betting your business on assumptions.

Monthly backup test (quick validation)

Run this test once a month to verify backups are working:

For UnderHost shared hosting with Backuply:

1. Log in to cPanel → Backuply
2. Verify a recent backup exists and shows a reasonable file size
   • Database backups: usually 50 MB - 2 GB (depends on site)
   • File backups: usually 100 MB - 50+ GB (depends on content)
3. Check the backup timestamp—is it from today or yesterday?
4. Download a database backup and verify it extracts properly:

   gunzip database.sql.gz
   # File should extract without errors
   ls -lh database.sql
   # Should show reasonable size, not 0 bytes

5. Spot-check file backup:

   tar -tzf files-backup.tar.gz | head -20
   # Should list files without errors

6. Document result: "Backup of MM/DD/YY verified—extracts without errors, expected size"

For VPS/Dedicated with cron-based backups:

1. Check backup logs:

   tail -50 /var/log/backup.log
   # Should show recent successful backups

2. Verify backup files exist and aren't empty:

   ls -lh /backups/ | tail -5
   # Should show recent files with size > 0

3. Verify offsite backups reached remote storage:

   ls -lh /offsite-backups/
   # Or check S3/Backblaze via CLI

4. Test extraction of latest backup:

   tar -tzf /backups/files-latest.tar.gz | head -20
   # Should list files without errors

Annual full recovery test (comprehensive)

Once per year, test a complete restore to verify everything works:

Step 1: Choose a recent backup

• Pick a backup from 1-2 weeks ago (has real data, not too old)
• Use a full backup (files + database combined)

Step 2: Set up a test environment

Option A: Test on a staging subdomain (if available):

• Many hosting plans offer free staging or subdomain hosting
• Restore backup to staging.yourdomain.com
• Test live, then delete after verification

Option B: Test on your local computer:

• Install local WordPress + MySQL (or equivalent for your platform)
• Restore backup files and database locally
• Verify website loads, all plugins work, images load

Option C: Test on a temporary VPS rental:

• Rent a $5-10 VPS for a few hours
• Restore backup there
• Test everything
• Delete the VPS

Step 3: Restore from backup

Follow your documented restore procedure (you HAVE one, right?):

• Download backup from UnderHost or remote storage
• Verify backup file integrity (correct size, extractable)
• Restore website files to test location
• Restore database to test MySQL instance
• Update configuration files (database credentials, domain URL, etc.)

Step 4: Validate restored data

Step 5: Measure recovery time

• Note start time when you begin download
• Note end time when restored site is fully functional
• Calculate total RTO (Recovery Time Objective)
• Is it acceptable? If not, what can speed it up?

Verification checkpoints

Backup integrity:

• ✓ Backup files exist and have reasonable size (not 0 bytes, not suspiciously small)
• ✓ Backup can be extracted without errors
• ✓ Checksums or hashes match (if provided by backup tool)
• ✓ Backup timestamp is recent (within expected schedule)

Data completeness:

• ✓ All database tables present and have data
• ✓ All website files present (website directories, uploads, config)
• ✓ All email accounts/data included (if applicable)
• ✓ Row counts in database tables are reasonable (not drastically lower than production)

Functionality:

• ✓ Website loads without errors
• ✓ Database queries execute properly
• ✓ Login works with restored credentials
• ✓ Forms accept input and process correctly
• ✓ File uploads work
• ✓ Third-party integrations function (payment processors, APIs, etc.)

Configuration:

• ✓ Database credentials are correct for test environment
• ✓ Domain/site URL is correctly configured
• ✓ Paths to uploaded files are correct
• ✓ SSL/HTTPS is properly configured

Data integrity validation

For databases:

# Check table row counts
mysql -u user -p password database_name -e "SHOW TABLE STATUS;"

# Check for MySQL errors in log
grep ERROR /var/log/mysql/error.log

# Verify database can be queried
mysql -u user -p password database_name -e "SELECT COUNT(*) FROM posts;"

For files:

# Count files in backup vs production
tar -tzf backup.tar.gz | wc -l
find /production/public_html -type f | wc -l
# Should be roughly similar (allowing for changes since backup)

# Check for corruption in text files
tar -xzf backup.tar.gz
grep -r "^[^[:print:]]*$" extracted-files/ | head -10
# Should find few/no binary-looking data in text files

Document your findings

Keep a backup test log:

Backup Test Log
===============

Date: 2026-06-06
Backup tested: database-2026-06-05.sql.gz
Backup size: 2.3 GB
Test environment: Local laptop with Docker MySQL

Results:
✓ Backup extracts without errors
✓ Database imports successfully (2,847 posts, 156,293 comments)
✓ WordPress admin loads
✓ Can log in as admin
✓ Blog home page displays correctly
✓ Images load properly
✓ Forms (contact, subscribe) work
✓ SSL certificate present and valid

Recovery time: 23 minutes (download 8 min, extract 5 min, import 10 min)

Issues found: None

Next action: All systems validated. Backup is confirmed working.
Next test: June 2026

Testing on shared hosting

• Download backup from cPanel/Backuply to your computer
• Extract and verify files locally (no special tools needed)
• If you can set up a staging subdomain, restore there and test live
• If no staging, at minimum extract and spot-check file integrity

Testing on VPS/Dedicated

• Create a test directory: `mkdir /tmp/restore-test`
• Restore database to test MySQL instance with different port (3307)
• Restore files to temporary directory
• Verify data integrity with queries and file checks
• Clean up test files when done

Related: Backup best practices | How to restore from backup | Disaster recovery planning

Related articles