Restore a WordPress site

Choose the recovery task

This guide restores site files, data, or configuration. If you only lost your authenticator or cannot sign in, use Recover your login.

Use Hub managed recovery when your account has a retained point and a connected destination. Use a downloaded archive when restoring from a private backup on a new host. Both require a server operator; selecting a point in Hub does not by itself complete a site restore.

Start managed recovery

Before starting, arrange a destination with your hosting administrator. Replacement requires a clean destination; repair affects an existing site. Keep public traffic, payments, outgoing mail, and webhooks isolated while restoring.

1. Sign in recently to the company that owns the source point with an owner or staff account authorized for recovery.
2. Have the operator connect the destination and run the preflight for the intended mode, as described in WP-CLI recovery.
3. Open Recovery in Hub.
4. Choose the Recovery point by source site and capture time.
5. Choose the Destination install. Check its host carefully.
6. Select Replace a lost site or Repair a hacked site under Restore mode.
7. Select Start recovery.
8. When Hub says Recovery request created. Continue on the destination install., have the destination operator continue the restore using the authorized job and plan.

Expected result: a recovery request exists for the selected point, destination, and mode. Creation is not completion. Check Recent recovery results after the destination work.

Example: to replace shop.example.com after losing its host, prepare an isolated replacement, select the last complete point from that shop, and choose the replacement host as destination. Do not select another live store.

Delegated sites can expose authorized downloads, but the managed restore form lists company-owned source points.

Read the result

• Complete: replacement configuration passed fresh-boot validation. Check the storefront, administrator sign-in, and checkout before directing traffic to it.
• Partial — action needed: repair configuration passed validation, but withheld settings and integrations need review. Reconnect payment, email, OAuth, CDN, and storage services deliberately.
• Needs attention: follow the displayed next action. An expired or revoked request needs a new preflight and request. A validation rollback needs its cause resolved before another attempt.

These results describe the managed configuration operation. They do not replace checking the restored site's files, database, media, plugins, and business flows.

Restore a downloaded archive on a new host

First download a complete backup, or retrieve the original complete archive from your private destination. Use only an archive from a trusted source.

1. Keep the original archive unchanged in a private directory. Limit access to the restore operator.
2. Read the archive's bundled RESTORE.md and use its restore/awthy-restore launcher. It supplies the matching runtime requirements and invocation; do not substitute a generic file extraction or database import.
3. Prepare the empty target directory, empty compatible database, and isolated restore runtime required by that guide.
4. Run the bundled verification and restore flow. Stop if archive integrity, completeness, runtime identity, or target isolation fails.
5. Confirm the source URL before choosing a replacement URL and optional site title when prompted.
6. After an isolated boot, check administrator sign-in, permalinks, media, plugin state, and WooCommerce data.
7. Reconnect withheld external services, test checkout safely, and only then move traffic.

A saved archive can be restored independently of the source host after download. Its filename is a label; the bundled verification checks the package contents. Never bypass a corrupt or incomplete package warning.

Convert older table formats on the copy

Older WordPress databases sometimes store tables in MyISAM instead of InnoDB. A restore keeps the format the archive recorded, and Awthy backs up and restores either one. Converting is optional, and the restored copy is the safe place to do it: never run it against the live site.

Ask for an assessment on the copy first. It changes nothing:

wp awthy conversion assess

It reports whether conversion is not required, available, partly blocked, or blocked; how many tables can move to InnoDB, with an estimated row count and total size; the tables that cannot, with a reason and what to fix; the database privileges the rebuild needs and any that are missing; and the extra space the rebuild is estimated to need, noting that free space on the database server cannot be measured from the application host. It also states the interruption to expect: writes to one table wait while that table is rebuilt, and the other tables stay available.

Then convert:

wp awthy conversion run

Add --tables=wp_posts,wp_postmeta to convert only the tables you name. Each table is converted and then verified one at a time: the command checks the new engine, the row count, and the indexes, stops at the first failure, and records an audit event for each table it converted. It refuses, and prints the reason, when conversion is blocked or a named table cannot be converted.

Conversion is safe to repeat. A table that is already InnoDB is verified and skipped, so a run that stopped picks up at the table it was working on, including when you name the same tables again with --tables. Stop a run with a single interrupt: the table being rebuilt finishes and is checked, then no further table is started. If that table was the last one, the run reports complete because nothing was left undone. A table change cannot be rolled back as part of a larger step, so tables finished before a failure stay converted.

Once the converted copy boots and works, take a new complete backup of it and update production through the restore path above, after comparing changes made on the live site since the copy was taken. Converting a copy proves nothing about production until that restore and its own checks are done.

If recovery stops

Keep the destination isolated and record the stage and safe error code. Do not repeatedly run a restore over a partly changed target: first confirm rollback or have the operator prepare a fresh empty destination.

If Hub shows no complete points, check the selected company, permissions, and capture status. If no destination is listed, finish connecting the destination. Give support the source and destination hosts, point time, and safe error code; keep archives, secrets, and grant links out of tickets.