Backup verification proves that expected data was captured; restoration testing proves that the organisation can use it. Both are required. A successful scheduled job can still produce an incomplete, encrypted-without-a-key or operationally unusable backup.
Use three levels of assurance
| Level | What it proves |
|---|---|
| Job monitoring | The scheduled process reported success or failure |
| Content verification | Expected files, database objects, size and timestamps are present |
| Restoration test | The site can be rebuilt and real functions operate at the selected recovery point |
Verify every run automatically where possible
- Backup completed within the expected window
- File and database size are plausible compared with history
- Expected components are present
- Encryption completed and the key is available through a separate route
- Off-site replication succeeded
- Retention did not delete every older recovery point
- Failure notifications reached a monitored owner
Plan a safe restoration test
- Select a representative recovery point and record why it was chosen.
- Prepare an isolated destination with no public indexing, real email or payments.
- Retrieve the backup using the documented business-owned accounts.
- Restore database, files and required configuration.
- Apply necessary secrets and external-service test settings.
- Run the acceptance checklist and record elapsed time.
- Delete or securely retain the test environment according to policy.
Test business functions, not only the homepage
| Site type | Checks |
|---|---|
| Brochure site | Pages, media, navigation, forms, email and editor login |
| Blog/publication | Posts, authors, categories, search, feeds and scheduled publishing |
| WooCommerce store | Products, orders at recovery point, test checkout, emails and scheduled actions |
| Membership site | User roles, protected content, login and renewal/test access |
| Booking site | Availability, test booking, reminders and calendar integration |
Record gaps honestly
Note missing files, manual configuration, outdated credentials, slow transfer, unsupported software and unclear ownership. A test that required undocumented specialist knowledge is only partially successful. Turn each gap into a named action with an owner and due date.
Test different failure scenarios
Rotate scenarios over time: accidental content deletion, failed update, full host loss, compromised administrator account and database corruption. The same local snapshot may work for one scenario and be unavailable in another.
Protect production data during tests
Do not send restored customer emails, charge stored payment methods or expose personal data on a public test URL. Use access controls, test-mode integrations and minimal data where the test objective allows it.
How often to test
Choose frequency according to change and impact. A low-change brochure site may use a scheduled annual or six-monthly full restoration plus checks after major platform changes. A store, membership service or frequently changed site should test more often and after material backup, hosting or architecture changes.
Also test when responsibility changes. A backup process known only to a departing supplier has not been operationally verified by the new owner.
Practical next step
Schedule one isolated restoration test using a recent independent backup and a written acceptance checklist. Measure the time from obtaining credentials to verified service.
Sources and date checked
This guide was checked on 21 July 2026. WordPress, plugins, hosting platforms and commercial terms change, so confirm the current documentation and licence details before making a material change.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.