Run a WordPress backup restore test and prove recovery works

A WordPress backup restore test should end with a working isolated copy, a timed recovery log, and a pass/fail record for the business tasks that matter. Restore a representative backup away from production, verify the files and database together, run defined checks, and record anything missing or unavailable.

What a WordPress backup restore test must prove

For a typical WordPress site, recovery needs both the database and the site files. The WordPress backup guidance (opens in a new tab) says you need both to fully restore a typical site and recommends treating them as one backup set created around the same time so they stay consistent. The database and files hold different parts of the site.

Do not assume payment or mail credentials sit outside that backup. WooCommerce gateways built on WC_Settings_API store their settings in WordPress options, so a database restore can bring live gateway keys into the isolated copy. WooCommerce Stripe, for example, uses the woocommerce_stripe_settings option.

Mail plugins can behave the same way. WP Mail SMTP stores plugin options in wp_options and can also read credentials from wp-config.php constants. A full files-and-database restore can therefore carry live mail settings too.

Reserve "outside dependency" for access that the backup does not contain. Examples include DNS or registrar access, a hosting account, object-storage credentials held outside WordPress, or keys available only through server environment variables.

Define recoverable assets

Write the acceptance target before you touch a backup. This stops a successful homepage load from becoming a false pass.

The WordPress file backup guidance (opens in a new tab) explains that files and the database are separate. It also calls out wp-content and wp-config.php as important parts of a file backup. Your recovery plan may rebuild WordPress core from a clean distribution instead of storing it, but that choice needs to be written down.

After creating your first backup, run one restore drill before you depend on it. Repeat the drill when the backup tool, host, restore method or site architecture changes. Set the ongoing schedule from how much change you can afford to lose and how quickly the site must return.

Restore in isolation, not over production

A restore test needs a target that cannot overwrite the live site. A local installation, private development site or separate staging environment can work. WordPress documents development copies (opens in a new tab) as a way to work without interrupting the live installation.

Give the restore target its own database credentials and its own file path. Do not allow normal browser traffic to reach a restored WooCommerce copy until you have made it safe.

Before the first page load, give the copy a URL different from production, disable WP-Cron, disable Action Scheduler's default queue runner, and block outgoing mail. WordPress checks for due WP-Cron tasks on page loads, so place this in the restored wp-config.php before browsing the copy:

define( 'DISABLE_WP_CRON', true );

WooCommerce Subscriptions has another safeguard, but do not depend on it alone. Its staging-site handling (opens in a new tab) switches to staging mode when the current site URL differs from the stored live URL. If the URL stays the same, Subscriptions can remain in live mode. Its staging mode also continues to trigger scheduled renewal and expiration events by default, although automatic subscription payments and subscription-related emails are suppressed.

After the database import, but still before the first browser request, clear or replace production gateway keys and switch each gateway you intend to exercise to its test or sandbox mode. Keep outbound mail blocked because WordPress, WooCommerce or another plugin may still send mail even when Subscriptions itself is in staging mode.

If the site uses WooCommerce Subscriptions, confirm the staging-mode notice or status appears when you first open the safe copy. Never run a restored WooCommerce copy under the production URL with live gateway keys in place.

Start the recovery timer before you retrieve the backup and credentials. That captures the access steps that would also exist during an incident.

Restore the same backup set you intend to trust

Use the restore path that matches the artifact you have. For a host snapshot or backup plugin package, use that product's documented restore flow on the isolated target. For separate file and database backups, WordPress documents the typical restore order as files first, then the database.

For a raw SQL dump, use a new empty database when possible. After restoring the files, replace the database constants in the restored wp-config.php with the isolated target's own credentials before running any reset or import command. Then confirm which database WP-CLI will use:

wp config get DB_NAME
wp config get DB_HOST

Both values must point to the isolated test database. Do not run wp db reset or wp db import while that wp-config.php still points at production.

If you need to empty a reused isolated database and its database user can drop and create that database, run the reset without --yes so you see the confirmation before it proceeds:

wp db reset
wp db import backup.sql

wp db reset runs DROP DATABASE and CREATE DATABASE statements using the database credentials loaded from wp-config.php. The database user therefore needs permission to drop and create that database. If your host does not give that user permission to create databases, recreate the empty test database through the host's database panel instead.

The wp db import reference (opens in a new tab) says the import uses database credentials from wp-config.php, does not create the database, and only performs the tasks defined in the SQL.

That last point matters during a restore drill. Importing a dump over an old staging database can leave a table that the dump never contained. A later check could mistake that leftover table for recovered data. Starting with an empty database makes everything present after the import attributable to the backup.

After the import, sanitize the restored payment and mail configuration before allowing a browser request. Make sure the restored URL differs from production, live gateway keys are cleared or replaced, outbound mail is blocked, WP-Cron remains disabled, and any required Action Scheduler runner protection is in place.

You do not need FileZilla. WordPress lists host backup software, FTP clients and shell access as ways to move site files. Use the method that fits your backup format and access level.

A staging URL must differ from production if you rely on WooCommerce Subscriptions to detect the clone as staging. If your restore tool does not handle stored URLs, use a method that understands serialized WordPress data. WP-CLI's wp search-replace command (opens in a new tab) handles serialized data, and its --dry-run flag reports changes without saving them.

Verify content and business tasks against the backup point

Check the restored site against what existed when the backup was created, not against production now. Content created after the backup point is outside that recovery point. Content that should have existed at the backup point but is missing is a recovery gap.

Use checks that prove both read and write behavior:

• Log in to WordPress admin with an authorized test account after the safety controls are in place.
• Open a known page or post that existed before the backup point.
• Load representative images and downloadable files.
• Save a disposable draft, refresh the page and confirm the change persists.
• Open functionality provided by custom code or a business-critical plugin.
• For a WooCommerce demo, open a product, add it to the cart and reach checkout with live payment credentials already removed or replaced.
• Record any task you cannot run because a required outside service is unavailable.

A pass means the expected item is present and the defined task works on the restored copy. A failure means something that should have been recoverable is missing or broken. Unavailable means the restore reached an outside dependency that you intentionally did not provide to the test environment.

Use this restore log and acceptance checklist

Copy this log for each drill. Fill it with the backup identifier and the exact target you used.

The next table is an illustrative demo scenario. Every row, item name, path, status and result below is illustrative, and every result is an expected result rather than an observed outcome.

Replace the illustrative rows with your own acceptance criteria before the test. If a required item is marked lost, the drill has found a backup gap. If a dependency is unavailable by design, decide before an incident whether that blocks recovery or has a separate recovery procedure.

Record recovery gaps and elapsed time

Use one timing rule on every drill: start when the responder begins retrieving the backup or access needed for recovery, and stop when the required acceptance checks finish. Record the file restore, database restore and acceptance milestones separately so the slow step is visible.

Treat the measured elapsed time as evidence for that tested backup, target and procedure only. A local restore time is not a promise for a different host, database size or recovery path. Treat the exercise as a small WordPress disaster recovery test with the same timer and acceptance rules each time.

Classify each gap so the next action is clear:

• Fix a backup gap when a required file, table or record from the backup point is missing.
• Fix a procedure gap when recovery depends on a manual step that was not documented.
• Fix an access gap when the person running the drill cannot reach a backup, credential or account they need.
• Record an unavailable dependency when the test intentionally excludes an outside service or account that is not contained in the backup.

Keep the failed acceptance row with the restore log after you fix it. On the next drill, that row becomes a regression check.

If the restore or move fails, reset the isolated target and try again

An isolated target is disposable. If a move or restore attempt fails, reset or recreate that target, correct the procedure, and restore the same backup again. Do not turn production into the retry target.

Whether the staging database is restored depends on the backup and restore scope. For an SQL dump, wp db import only performs the tasks defined in that SQL. It does not prove that unrelated tables already present in the target came from the backup.

For a valid drill, import into a new empty database or empty the isolated target first. Before using wp db reset, replace any restored production database credentials in wp-config.php with the isolated database credentials and confirm DB_NAME and DB_HOST with wp config get. The reset command drops and recreates the database named by that configuration, so it must never run against a wp-config.php that points at production.

If the test database user lacks permission to create the database, recreate the empty database through the host's database controls instead of using wp db reset. Then import the backup into that empty target.

If the package is files-only, the database is not restored. Check the package contents and the target database credentials before every retry.

Put the verified restore path into normal maintenance

Once recovery is repeatable, keep it as the fallback behind testing WordPress plugin updates before they reach production so update work starts with a known recovery path. If you want backup ownership, restore drills and recovery documentation handled as ongoing operations, the WordPress maintenance service covers that work.