Test a website backup restore in an isolated directory and database

A restore test is the point where a backup becomes evidence of recoverability. Checksums and successful upload messages cannot tell you whether the database imports, the copied configuration connects to the correct service or the application can read its uploads. An isolated rehearsal finds those gaps without overwriting the website your customers are using.

Define an isolated target and a test plan

Choose a separate document root, database and credentials. Prefer a test environment that cannot reach production-only dependencies. A different hostname by itself is not isolation: a copied configuration can still connect to the live database, send real customer emails or run a payment capture.

Prepare a short acceptance checklist before restoring. Include known pages, a representative upload, a controlled administrator login, a database-backed operation and any essential background job. Protect the test site with authentication or network access controls; a noindex directive is not an access restriction.

Validate the archive before extraction

cd "$HOME/private-backups/20261108-120000"
sha256sum -c SHA256SUMS
gzip -t site-files.tar.gz
tar -tzf site-files.tar.gz | head -n 30

Use the actual backup directory, not the example timestamp. Review the archive's paths and source before extracting it. Archives and SQL files are inputs that can have security consequences; do not test an untrusted archive as root or import an unfamiliar dump with a privileged database account.

A failed hash or decompression check should stop the rehearsal until you locate a good copy. Record the failure rather than generating a replacement checksum for corrupted bytes and then calling the verification successful.

Extract files and import only into the test database

umask 077
RESTORE_DIR="$HOME/restore-tests/site-20261108"
mkdir -p "$RESTORE_DIR"
tar -xzf site-files.tar.gz -C "$RESTORE_DIR"
find "$RESTORE_DIR" -maxdepth 2 -type d -print

mariadb --user=restore_user --password restore_test < database.sql

Create restore_test and its restricted user beforehand using cPanel or your database administration process. Inspect the dump for database-selection statements, definers and stored objects before import. A command-line database argument does not prevent SQL inside a dump from naming another database; permissions are an important part of keeping the test isolated.

Check the import result and errors, then verify expected tables and sample records. Do not grant broad global privileges simply to silence a failed import. Missing definers, collations or extension requirements are exactly the dependencies a restore test is meant to discover.

Reconnect the copied application without reconnecting production

Update the copied configuration with the test database and environment settings. Change application secrets where the application supports it and disable production webhooks, scheduled jobs and outbound email. Keep the source service untouched while you establish that the test copy stands on its own.

wp --path="$RESTORE_DIR/public_html" option get home
wp --path="$RESTORE_DIR/public_html" option get siteurl
wp --path="$RESTORE_DIR/public_html" search-replace \
  'https://example.com' 'https://staging.example.com' \
  --skip-columns=guid --dry-run

Only run these commands after confirming that the copied wp-config.php points at the isolated test database. Review the dry-run table scope, then perform the intended change without --dry-run if needed. Do not use a global text replacement on a SQL dump when the application stores serialized data or structured values.

Test the intended virtual host and application behavior

curl --resolve staging.example.com:443:203.0.113.20 \
  --fail --show-error --silent -I \
  https://staging.example.com/

Replace the documentation address with the staging server's actual IP. This keeps the hostname used for HTTP and certificate validation while selecting the destination address. The staging service still needs a valid certificate for that hostname; do not bypass TLS verification to hide a deployment mistake.

A successful header response is only the first check. Log in with a controlled test account, open representative records and files, test an application operation and inspect logs for errors. Confirm that mail and billing activity stay inside the test boundary.

Measure the result and improve the next backup

Record the backup age, extraction and import duration, application repair steps and the final acceptance result. A usable recovery procedure should identify who performs each step and which credentials, licences or external services are required.

• Document missing files, incompatible runtimes and database-object errors.
• Confirm that backup retention provides enough history for the incidents you expect.
• Repeat the test after major application or infrastructure changes.
• Remove or secure the test copy when its purpose is complete, following your data-retention process.

Primary documentation

• MariaDB logical backup reference
• WP-CLI search and replace
• curl command-line reference
• cPanel Backup Wizard