How to Perform a Backup Restore Test

How to Perform a Backup Restore Test

Photo by Ivo Brasil on Pexels

Knowing why to test is one thing; knowing how is another. This lesson walks you through a complete, practical restore test from start to finish. Follow these steps with your own backup system.

Preparation: What You Need Before Testing

• A test environment: a spare server, a VM, or a Docker container. Never test restores on your production system — you could overwrite live data.
• Your backup tool installed on the test machine.
• Access credentials and encryption keys for the backup repository.
• A stopwatch or timer to track recovery time.
• A checklist of critical files to verify (from your data audit in the "What Data" lesson).

Step 1: Document Your Current State

Before starting, note what you're testing:

# Record key file counts from production
find /home -type f | wc -l          # total user files
find /var/www -type f | wc -l       # total web files
du -sh /home /var/www /etc          # sizes

# Check database row counts (if applicable)
mysql -e "SELECT COUNT(*) FROM customers;" -u root -p

Step 2: Start the Timer and Initiate Restore

Time is a critical metric. In a real disaster, every minute costs your business money. Start timing from the moment you begin the restore.

# Borg restore
borg extract /backups/repo::hostname-2026-01-15 --target /tmp/restore

# Restic restore
restic -r b2:bucket:backup restore latest --target /tmp/restore

# Duplicati: Use the "Restore" wizard in the web UI

Step 3: Verify Restored Files

After restore completes, compare file counts and sizes:

# Compare restored file count
find /tmp/restore/home -type f | wc -l
find /tmp/restore/var/www -type f | wc -l
du -sh /tmp/restore/home /tmp/restore/var/www

# Spot-check individual files
cat /tmp/restore/etc/nginx/nginx.conf  # is it valid?
ls -la /tmp/restore/home/user/         # are user files present?

Step 4: Test Database Restores

For database backups, restore to a test database instance and verify data integrity:

# Restore MySQL dump to test instance
mysql -u testuser -p testdb < /tmp/restore/db_backup.sql

# Verify row counts match production
mysql -e "SELECT COUNT(*) FROM customers;" -u testuser -p testdb
mysql -e "SELECT COUNT(*) FROM orders;" -u testuser -p testdb

# Check for corruption
mysqlcheck --all-databases -u testuser -p

Step 5: Verify Application Functionality

If you backed up a web application, restore it to a test server and verify it runs:

1. Restore web files and database to the test server.
2. Update the test server's configuration to point to the restored database.
3. Access the application via a test URL.
4. Log in with a test account. Can you navigate, search, create records?
5. Compare a few records between production and restored versions — do they match?

Step 6: Document the Results

After the test, fill out a restore test report:

• Date and time of test
• Backup used: Which date's backup, which tool, which repository
• Restore time: Total from start to verified functional state
• Files verified: Count, spot-check results, any missing files
• Database verified: Row counts matched? Any corruption?
• Issues found: Document every problem, no matter how small
• Action items: What needs to be fixed before the next test

Step 7: Clean Up and Fix Issues

Delete test data. Fix any issues found and re-test if necessary. Update your backup documentation with lessons learned.

Sample Restore Test Template

RESTORE TEST REPORT
Date: _______________
Backup tested: _______________ (date/tool)
Restore started: ______  Restore completed: ______
Total restore time: ______

Files verified: __ / __ (passed/total)
Database verified: Y / N  Row count match: Y / N
Application functional: Y / N

Issues found:
1. _______________
2. _______________

Action items:
1. _______________
2. _______________

Next test scheduled: _______________

Key Takeaways

• Never test restores on production — always use a separate test environment.
• Time your restores and compare against your business's acceptable downtime.
• Verify not just file existence but content, database integrity, and application functionality.
• Document every test in a standard report format — this becomes your proof of readiness.
• Fix issues immediately and re-test until the restore passes cleanly.