A backup is only useful if it restores cleanly. Many small business websites have automated backup jobs running in the background, but nobody has checked whether those files can rebuild the site after a failed update, hosting problem, or accidental deletion. That is the gap this checklist is designed to close.
This guide focuses on restore testing rather than general backup planning. For the broader strategy around files, databases, off-site storage, and retention schedules, use the main WordPress and custom PHP backup strategy guide. This page is the practical companion: how to prove the backup works before you need it under pressure.
Why restore testing matters more than backup frequency
Daily backups sound reassuring, but frequency does not prove recoverability. A daily archive can still be incomplete, corrupt, stored in the wrong place, or missing the database that contains the actual website content. The real question is whether a clean copy of the site can be restored somewhere safe and made to run.
Restore testing exposes problems while there is still time to fix them. It can show that uploaded media is missing, that the database export is too old, that environment variables were not captured, or that a plugin depends on a setting stored outside the normal WordPress database. These are manageable problems during a planned test. They become business disruption during an emergency.
What a complete restore test should prove
A useful restore test should answer five questions. Can you access the backup? Can you extract the files? Can you import the database? Can the restored site load in a browser? Can the important business functions still work?
For a brochure website, important functions might mean contact forms, page images, navigation, and admin login. For an e-commerce or booking site, it also means checkout, appointment flows, order emails, payment callbacks, and any integrations that move customer data between systems.
Step 1: Choose a safe testing environment
Never run a restore test directly over the live website unless the live site is already broken and you are deliberately recovering it. Use a staging environment, temporary subdomain, local development copy, or separate hosting space where mistakes cannot affect visitors.
The test environment should be close enough to production to reveal real problems. Match the PHP version, database engine, web server, and key extensions where possible. If production runs on PHP 8.3 with MariaDB, a restore tested on a completely different stack may miss compatibility issues.
Step 2: Confirm you have every backup component
Before restoring anything, check the backup package. A WordPress site usually needs the database, the wp-content directory, theme files, plugin files, uploads, and wp-config.php. A custom PHP site may also need a .env file, custom upload directories, cron scripts, queue workers, private storage folders, or server configuration.
Do not assume the backup tool captured everything. Look inside the archive and confirm that the expected folders are present. Check file sizes for obvious anomalies. A database dump that is only a few kilobytes for a mature site is a warning sign. A file archive with no uploads folder is another.
Step 3: Restore files and database separately
Restore the file archive first, then import the database. Keeping these steps separate makes troubleshooting easier. If file extraction fails, you know the archive or permissions are the issue. If the database import fails, you can inspect the SQL dump, character set, database size, or user permissions without confusing it with file problems.
mysql -u username -p database_name < backup.sqlFor compressed backups, extract the archive into the test web root and check ownership and permissions before loading the site. Incorrect permissions can make a restored site appear broken even when the data is intact.
Step 4: Update configuration for the test location
A restored copy usually needs configuration changes before it loads. WordPress may need the site URL changed in the database or configuration. Custom PHP applications may need a different database name, test API keys, storage paths, or mail settings.
Be careful with email and payment integrations. A staging restore should not send real customer emails, charge cards, or push data into live CRM tools. Disable outbound mail or route it to a test mailbox. Replace live payment keys with sandbox keys before testing transaction flows.
Step 5: Check the restored site like a user
Open the restored site in a browser and test the paths that matter. Do not stop when the homepage loads. Visit service pages, blog posts, forms, search, login, checkout, booking flows, and any page that drives enquiries or revenue.
Look for missing images, broken links, layout errors, PHP warnings, failed forms, blocked scripts, and redirect loops. If the restore looks correct but core actions fail, the backup is not complete enough for business recovery.
Step 6: Record restore time and gaps
A restore test should produce notes, not just a pass or fail. Record the backup date, where it was stored, how long extraction took, how long database import took, which fixes were required, and whether any data was missing. This gives you a realistic recovery-time estimate.
If the restore took four hours in calm conditions, it will not take ten minutes during a live incident. That matters for planning. A business that relies on enquiries, bookings, or online payments needs to understand how long it can tolerate downtime.
Common restore test failures
The most common failure is missing uploaded media. WordPress backups sometimes capture the database but miss the uploads directory, leaving restored pages full of broken images. Custom PHP sites can fail in a similar way when uploaded files are stored outside the main web root.
Another common issue is an incomplete database export. Large databases may time out during export, producing a file that starts correctly but ends abruptly. Always check that the export completed successfully and that the final tables are present.
Configuration gaps are also frequent. A missing .env file, incorrect database password, or hard-coded production path can stop an otherwise good restore from loading. This is why documenting the technical setup matters as much as storing the archive.
How often should you test restores?
For most small business websites, quarterly restore testing is a sensible baseline. Test more often if the site handles payments, bookings, client portals, membership content, or frequent updates. Also run a restore test after any major hosting migration, PHP upgrade, redesign, or backup tool change.
Restore testing should be part of normal maintenance, not a one-off exercise. The wider small business website maintenance checklist gives a good routine for pairing backup checks with updates, security reviews, and performance monitoring.
When to ask for technical help
If you cannot restore the site into a safe test environment, if the database import fails repeatedly, or if the restored site loads with errors you cannot explain, get help before the next emergency. A failed restore test is useful evidence that the current setup needs attention.
Backup reliability also depends on hosting quality. Full disks, old PHP versions, poor file permissions, and unstable shared hosting can all undermine recovery. If the test reveals hosting-level issues, review the common hosting mistakes that hurt small business websites before assuming the backup tool is the only problem.
The simple pass or fail standard
A restore test passes only when a separate copy of the website loads, the database content is present, the media files display, admin access works, and the main enquiry or sales path completes without errors. Anything less is a partial restore. Partial restores are still useful for diagnosis, but they should not be treated as proof that the business can recover quickly after a real incident, outage, migration, or rebuild.