Answer box: Test a website backup by restoring it into a disposable environment with its own files, database and credentials—not over your live website. For WordPress, restore both the files and database. Before the restored application runs, restrict access, block outbound email and external integrations, and disable scheduled jobs. Then check content, media, administration and safe form submissions. Record the recovery point, elapsed time, failures and untested dependencies. A completed restore is useful evidence, but it is not proof that every production function will work. (developer.wordpress.org)
This guide is for a small, single-site WordPress installation. Multisite networks, stores, membership systems and sites containing sensitive customer records need additional checks tailored to their dependencies. WordPress documents separate migration considerations for multisite; do not apply a single-site procedure unchanged. (developer.wordpress.org)
1. Define what a successful recovery must include
Start with two questions: How much recent data could you lose? How long could the website be unavailable?
These are your recovery objectives:
- Recovery point objective (RPO): the maximum acceptable data-loss window, measured in time.
- Recovery time objective (RTO): the maximum acceptable delay between service interruption and restoration.
They are targets, not promises made by the backup tool. AWS’s recovery guidance recommends testing whether your actual recovery capability meets those targets. (docs.aws.amazon.com)
Write down your acceptance criteria before restoring anything. For a basic publishing site, a proposed checklist is:
- An administrator can sign in.
- Expected posts, pages and settings are present.
- Images and downloads load from the restored environment.
- Navigation and representative permalinks work.
- A form accepts a dummy submission without contacting real recipients.
- No unexplained fatal errors appear during those checks.
Separate restoring the application from recovering the complete service. Your test may exclude public DNS changes, production certificates or reconnecting third-party services. Record those exclusions rather than presenting the isolated restore as a complete outage rehearsal.
2. Confirm what the backup contains—and what the host can restore
A typical WordPress recovery needs two components:
| Component | What to look for |
|---|---|
| Database | Posts, pages, comments, settings and plugin data stored in database tables |
| Files | WordPress code, themes, plugins, uploads and configuration files |
Downloading the WordPress directory does not normally capture the separate database. Conversely, a database export does not include your themes, plugins or uploaded media. Keep files and database together as an identifiable backup set, with their timestamps recorded. (developer.wordpress.org)
Before starting, ask your provider or inspect its current documentation:
- Can this backup restore to staging, or only overwrite its original environment?
- Does restoration replace files, database tables or both?
- How long is this backup type retained?
- Can you download it for recovery elsewhere?
- Are external storage, email accounts and server configuration included?
- Does the process require provider support or a particular restore tool?
These details are provider-specific. For example, Kinsta documents restoration of live backups to staging, requires the staging environment to exist first, and says retention varies by plan and backup type. Its external backups cannot be restored directly through the same MyKinsta workflow used for automatic, manual and system-generated backups. Verify your own host’s rules rather than assuming equivalent behavior. (kinsta.com)
Preserve the original backup. Perform extraction, inspection and test-specific edits on a working copy.
3. Isolate the test before the application starts
A separate hostname is not sufficient isolation. Establish the boundaries before the restored WordPress application handles requests.
Use this preparation checklist:
- Create a separate document root and database.
- Give the test database its own user, with no access to the live database.
- Use local-only access, authentication or an IP restriction.
- Keep production DNS unchanged.
- Block outbound email and external API traffic at the environment level where possible.
- Disable host schedulers, workers and application task runners.
- Remove or replace production integration credentials in the test copy.
- Verify that storage configuration cannot write to a production bucket.
These are proposed safeguards; confirm how your hosting or local environment implements each one. Do not assume a service called “staging” disables side effects. Kinsta, for example, documents that staging transactional email is enabled by default and warns that social-scheduling plugins may publish from staging. (kinsta.com)
For the test copy only, WordPress documents this configuration setting:
define( 'DISABLE_WP_CRON', true );
Add it before WordPress loads, without duplicating an existing definition. It disables the normal page-load triggering of WP-Cron. Also disable any separate scheduler that directly invokes wp-cron.php, plus plugin-specific workers or queues. The setting is not a replacement for checking those other execution paths. (developer.wordpress.org)
Use search-indexing restrictions as an additional precaution, not as access control. Keep the restored copy behind an actual access restriction, especially if its database contains private information.
4. Match the recovery environment before troubleshooting
Make the first test about restoration, not restoration plus a software upgrade.
Record the original WordPress, PHP, database, plugin and theme versions. Note the database export tool and, where available, its version. Choose a compatible target environment, then document differences you cannot reproduce.
Database compatibility includes the import client, not just the database server. MariaDB documents that mariadb-dump adds a sandbox-mode command that older MariaDB command-line clients and the MySQL mysql client cannot interpret. An import error can therefore involve tool compatibility rather than proving that the backup itself is corrupt. (mariadb.com)
Before changing the dump, capture the exact error and check the documentation for the exporting and importing tools. Do not blindly delete unfamiliar SQL statements or repeatedly retry against a partially imported database.
Use a new, empty test database for a clean attempt. If a restore fails, retain its logs, discard only the disposable target, and start again after identifying the cause.
5. Worked example: restore a small WordPress publishing site
Suppose your backup contains a file archive and a SQL export for example.com. The site uses a theme, uploaded images and a contact-form plugin. This is an illustrative procedure, not a report of a measured restore.
Step 1: Prepare the disposable target.
Create a local or restricted test site with a new database and test-only credentials. Establish email, network and scheduler restrictions from section 3. Start the timing record.
Step 2: Restore the files.
Extract the working archive into the test document root. Confirm that the expected theme, plugins and uploads are present. Before loading WordPress, edit the copied wp-config.php to use the test database host, name, user and password. Keep the table prefix consistent with the imported tables. WordPress’s backup guidance describes restoring files first, then importing the database. (developer.wordpress.org)
Step 3: Import the database.
Select the empty test database explicitly in your import tool. Import the SQL export and read the completion report. WordPress warns that database restoration replaces the selected database’s contents, so confirming the destination is essential. Do not select the live database. (developer.wordpress.org)
Step 4: Adapt addresses in the test copy.
Review the copied site address, redirects and configuration. If the clone uses a different hostname, use a WordPress-aware replacement tool rather than a blind text replacement. WP-CLI’s search-replace supports serialized PHP data and offers a dry run that reports changes without saving them. Review that report before applying replacements to the disposable database. (developer.wordpress.org)
Limit replacements to the intended site’s tables and addresses. WordPress’s migration guidance says not to change the posts’ guid values. Check for configuration overrides or hard-coded redirects that still point to production. (developer.wordpress.org)
Step 5: Open the restricted copy.
Confirm that the browser stays on the test address. Sign in and perform the checks below. If you must deactivate a plugin to make the site load, record that limitation; do not call it an unchanged, complete recovery.
6. Check integrity, media and real user actions
Use two layers of validation.
Technical checks: Review extraction and import errors, confirm expected tables and files exist, and inspect application logs. Where supported, WP-CLI’s db check invokes a database-table check using the credentials in wp-config.php. This is useful structural evidence, not a check that every expected post or submission is present. (developer.wordpress.org)
WP-CLI’s core verify-checksums compares WordPress core files with WordPress.org’s checksums. It needs access to retrieve those checksums; allow that specific access only if your isolation policy permits it. A passing core check does not validate uploaded media, custom themes or the whole application. (developer.wordpress.org)
Functional checks: Use a repeatable sample rather than browsing randomly.
| Check | Suggested test |
|---|---|
| Content | Open a recent post, an older post and a representative page |
| Media | Open an image at full size and download a document |
| Editing | Save a dummy draft and upload a disposable image |
| Navigation | Follow menus, categories and representative permalinks |
| Forms | Submit dummy data with external delivery blocked |
| Logs | Review errors generated during these actions |
For forms, distinguish validation, local storage and notification delivery. If the plugin stores submissions, confirm the dummy entry exists. If a local mail-capture service is configured, inspect the captured notification. Otherwise, mark delivery untested.
Inspect media requests too: an image displayed from the live domain is not evidence that the restored upload exists. Treat production storage and API dependencies as separate recovery items.
7. Record elapsed time and avoid false passes
Record these milestones:
- Test started.
- Backup retrieved and accessible.
- Environment ready.
- Files restored.
- Database imported.
- Required functional checks passed.
Include waiting, troubleshooting and validation—not merely the time shown by the import tool. Compare the result with your recovery objective, while noting which real-outage tasks the rehearsal excluded. (docs.aws.amazon.com)
Common false passes include:
- “The archive opens.” Continue through import and functional checks.
- “The homepage loads.” Check administration, media and representative workflows.
- “Staging is automatically safe.” Verify email, integrations and task execution.
- “Everything works with several plugins disabled.” Report the reduced scope.
- “The latest content is missing, so restoration failed.” Compare content with the backup’s recovery timestamp.
- “One successful test proves every backup.” Repeat with another recovery point and after meaningful infrastructure changes.
Your report should state passed, failed, partially passed or blocked, with reasons. Avoid an unexplained green checkmark.
8. Clean up the clone without deleting the evidence
Before deletion, save a compact recovery record:
- Backup identifier, timestamps and components.
- Target versions and environment differences.
- Restore steps and required permissions.
- Timing milestones.
- Checks passed, failures and untested dependencies.
- Corrective actions and the next test trigger.
Then remove only the disposable resources: test files, database, database user, temporary access accounts, mail captures and unnecessary extracted archives. Revoke test-only credentials and remove temporary routing entries.
Double-check resource names before deletion. Do not delete the original backup, alter production schedules or use a “push to live” control. If keeping the clone temporarily, leave its access restrictions and side-effect protections in place.
The useful result is a repeatable recovery procedure with explicit limits—not simply proof that a ZIP file exists.
Read next: How to Protect AI API Keys and Other Secrets on a Website Host