“Backup complete” may mean only that a job reached its final screen. A usable recovery set needs readable files, a complete database, enough metadata to rebuild the environment and a restore path that has actually been exercised. Protect the only copy before experimenting.
Preserve the recovery set
Duplicate the archive and database dump to separate storage. Record filenames, sizes, timestamps, backup-tool version and any multipart sequence. Work from copies and calculate checksums so failed transfers or edits are detectable.
Do not upload the sole backup into the broken site’s public directory. A large archive can expose private data and consume remaining disk.
Read the restore error and logs
Identify the failing phase: download, extraction, database import, URL replacement, file placement or final activation. Save the first meaningful error, not only the last timeout page.
If the browser loses connection, check whether the server-side process continued. Starting it again immediately can create overlapping extractions or duplicate imports.
Verify archive structure and integrity
List the archive contents without extracting over a live installation. Confirm it includes WordPress content, configuration where expected, hidden files and all numbered volumes.
sha256sum site-backup.zip
unzip -t site-backup.zipA valid ZIP can still be an incomplete WordPress backup, so inspect content as well as container integrity.
Inspect the database dump
Confirm the SQL file is non-empty, ends cleanly and contains expected WordPress tables and recent records. Note charset, collation and source database version. Some tools store the database in a separate archive that is easy to omit.
Search cautiously for HTML error pages saved with an .sql extension. Do not treat file size alone as proof.
Check destination capacity
A restore may require space for the archive, extracted files, database and temporary working copies simultaneously. Check disk, inodes, database quota and file-size limits.
Clear only known disposable files. Deleting the current site or older backups before confirming an off-server copy removes rollback options.
Match the restore method and version
Use a backup plugin/version compatible with the archive format. Multipart sets must be complete and consistently named. Encryption passwords and remote-storage credentials are separate requirements.
If the automated importer cannot handle the environment, extract and import through a controlled manual process supported by the host. Do not edit proprietary archive internals blindly.
Rebuild into an isolated location
Restore to staging or an empty document root and database, not directly over production. Configure the target PHP version and required extensions. Capture each step so it can be repeated.
When import fails on a specific SQL statement, diagnose privileges, collation, packet size, definer or version compatibility. Recreate the empty database before retrying if the previous attempt was partial.
Correct environment-dependent values
After a successful restore, update database credentials and use serialization-aware URL replacement if the hostname changed. Review absolute paths, cache configuration, mail settings and security rules tied to the old server.
Regenerate disposable caches; do not indiscriminately delete uploads or plugin data.
Prove application recovery
Test public pages, login, editor, media, forms, email, scheduled events and any business-critical workflow. Compare table/row counts and recent content with the source. Scan logs for errors caused by the restored code.
Only then plan a DNS or production switch, retaining the original set and a rollback window.
Turn backups into verified recovery
Recurring maintenance should monitor job completion, off-server copy presence, integrity, retention and storage capacity. Schedule isolated restore tests and record recovery time. A backup is operational evidence only after it has rebuilt a working WordPress site; until then, it is an untested promise.