A successful backup notification proves that a process ran, not that the website can be recovered. A proper test rebuilds the site in isolation, measures the work required and records defects before an emergency makes them expensive.
Define the recovery target
Choose the exact backup date and state what must return: files, database, uploads, configuration and any external dependencies. Set a recovery-time target and identify business-critical journeys.
Do not use production as the test destination. Prepare a restricted staging hostname or local environment with no public indexing.
Inventory the backup set
List every archive, database dump and multipart volume with size and timestamp. Confirm encryption keys, storage credentials and restore software are available to authorised people.
Record checksums before copying:
sha256sum wordpress-files.tar.gz wordpress.sql.gzA matching hash detects transfer damage but does not prove logical completeness.
Prepare an isolated destination
Use an empty document root and database. Match source PHP and required extensions initially, with sufficient disk, inodes and database quota. Block public access and outgoing transactional email.
Add noindex as a secondary precaution. Never rely on it as the only access control for a restored copy containing personal data.
Restore without hidden source access
Perform the test as though production were unavailable. Download from the documented backup location, extract files and import the database using the recorded procedure.
Capture commands, elapsed time and errors. If an undocumented password or plugin licence is needed, that is a recovery defect even if someone eventually finds it.
Reconfigure environment safely
Create staging database credentials and adjust wp-config.php. Replace domains with a serialization-aware tool. Disable real payment, CRM, webhook and SMTP endpoints so the restored copy cannot contact customers.
Review absolute paths and server-specific cache or security settings. Regenerate disposable caches after source data is correct.
Verify data completeness
Compare table counts, selected row counts, latest posts and recent business records with the backup’s expected time. Open older and newer media items and verify files exist rather than merely database references.
Check users and roles without exposing passwords. Never email a restored user list as part of testing.
Exercise WordPress functions
Test login, password-reset generation without delivery, editor save, media upload, permalinks, search, REST and scheduled events. For forms or commerce, use sandbox endpoints and clearly marked test records.
Review PHP, web-server and WordPress logs after testing; a visually correct homepage can hide failing background work.
Measure recovery performance
Record time to obtain access, download, restore, configure and validate. Note manual steps and the largest delay. Compare results with the required recovery time and recovery point.
If the database import dominates, improve the server-side procedure rather than simply raising browser timeouts.
Test failure handling as well as success
Confirm the team knows what to do when one archive volume is missing, the storage account rejects access or the destination lacks space. Do not deliberately damage the only recovery set; simulate the condition with test copies. The runbook should say when to stop, who can authorise an alternative restore point and how to preserve error evidence. This turns an improvised emergency decision into a controlled recovery branch.
Clean up the test responsibly
Save the non-secret test report, then remove the restored environment and temporary archives according to retention policy. Revoke temporary credentials and confirm staging DNS or access rules no longer expose data.
Preserve the original backup until retention expires.
Repeat on a useful schedule
Test after major hosting, PHP, backup-tool or site architecture changes and periodically thereafter. Rotate backup dates so testing does not always select the same known-good set. Recurring maintenance should track restore success, elapsed time and unresolved defects. The result is evidence that recovery works, not another green dashboard.