Restores

Starting a restore

Restore… on a site's Backups page — at the top, or on a backup in the list — walks through three steps:

1. Backup. Pick the moment to go back to. Only verified backups that still have a copy are offered, newest first, with their type, size, who made them and their note.
2. What to restore. Full puts files and database back to that moment; Database only restores content, users and settings and leaves the files; Files or tables restores only the folders, files and tables you choose — one plugin, a folder, wp-config.php, single tables — and leaves the rest as it is. Under it, What you lose lists what the platform recorded since the backup: update rounds that are undone, changes in the activity log, and newer backups that stay available.
3. Check and start. The checks that decide whether the restore can start — the worker can be reached, a copy of the backup is available, nothing else is running on the site — shown before you start rather than as a refusal afterwards, and the two safeguards below.

From a backup's Details you can also tick folders, files or tables in its contents and choose Restore selection…; the steps open with them chosen.

The fleet-wide Backups page offers Restore where a restore point exists.

Restoring chosen folders and files

When you choose folders and files, the steps compare them with the newest backup of the whole site taken after the one you picked — the closest record of the site as it is now — and say how many files go back to how they were, how many come back because they were removed since, and how many were added since and are only on the site, naming the first few.

A chosen folder can hold files that are only on the site: added after the backup, so the backup does not have them. Under Advanced, closed by default, you choose what happens to them:

• Automatic (the default) — plugins, themes and WordPress itself end up exactly as in the backup, so a plugin you take back to an older version keeps none of the newer version's files; uploads and other content keep what was added since, because people add files there on purpose.
• Keep everything — nothing added since is removed. Safe for content, but a plugin or theme can be left a mix of two versions, and a file someone slipped in stays.
• Remove everything — every chosen folder ends up exactly as in the backup. Cleanest, but uploads and other files added since are removed too; with the safety backup on, Undo restore brings them back.

The last step lists, per chosen folder, which of the two will happen. Removing files needs a recent worker on the site; for an older one everything is kept and the choice says so. Files a backup never contains, such as caches and logs, are never removed.

Safeguards

Back up what this replaces first (on by default). Before anything is replaced, a backup of the site as it is now — of the same part: everything, the database, or the chosen folders, files and tables — is made and verified. The restore starts only once it is ready; if it cannot be made, the restore ends without touching the site and says why. This backup is kept on the site, and removed seven days after the restore ended.

Undo restore. A restore that made such a backup offers Undo restore once it has ended, also when it failed part-way. Undo restores that backup, so the site goes back to how it was just before. The safety backup, and Undo with it, is kept for seven days after the restore ended and then removed automatically.

Check the site afterwards (on by default). Once the restore has ended, the platform looks at the site: whether the front page answers and does not show WordPress's critical-error page, a database connection error or the maintenance notice, and whether the site's connection with WP Octo still works. The outcome is shown with the restore. A check the platform cannot make — a firewall in front of the site answers instead — is shown as unknown, never as passed. For a site the platform cannot reach directly, the connection check passes once the site has been in contact again.

What happens

• From the site's copy, the worker puts the database back and then the files, one piece at a time. A failure part-way rolls back rather than leaving half a database; the live site is unavailable only for the moment the new database is switched in.
• From the external copy, the platform first brings the backup back onto the site: the worker downloads it from object storage piece by piece, through links the platform hands it that are valid for a limited time, and only a site holding a complete, verified copy is then asked to restore. A link that expires mid-download is renewed; the site keeps every piece it already has.

The worker refuses a restore from a copy on the site whose files are not all there, rather than restoring whatever happens to be in the directory; the platform then restores from the external copy when there is a whole one, and says so if there is not.

A restore is the only thing that runs on the site while it runs: no backup, update round or worker update starts on that site until it has finished.

Following and stopping a restore

While a restore runs, the top of the site's Backups page shows it as a row of phases — safety backup, sent to the site, fetch copy, prepare, files, database, site check — and keeps the outcome there for a day afterwards, with the reason when it did not finish.

Stop ends a restore under way. What it has already put back stays as it is, so the site can be partly restored; Undo restore brings it back to how it was before, when a safety backup was made.

What a restore keeps

Since worker 2.3.0 a restore keeps the site's connection to the platform and the work in flight, rather than rolling them back to the backup's day.

The Restores page

Each site's Restores page lists its restores with their phase — safety backup, pending, fetching, preparing, processing, completed, failed, cancelled — the copy each read from, and the outcome.