Restore a backup

What it does

A restore brings back the database (posts, pages, settings, users), the files (plugins, themes, uploads), or both, from any backup marked Verified.

First the backup is unpacked into a separate folder and the database is loaded into separate tables, and every row is counted. If anything does not match, the restore stops and the site is not changed at all.

Only then is the new copy swapped in, which takes seconds. Visitors see a short maintenance message while that happens.

The site as it was before the swap is kept on the server. Check the site, then click Keep the Restore to tidy up, or Roll Back to put everything back as it was just before the restore.

Why it matters

A restore that fails halfway can leave a site worse off than before. Checking everything first and swapping it in all at once means the site is either fully the old one or fully the restored one, never a mix. If PHP stops in the middle, the restore carries on or puts things back by itself.

Restore a backup

1. Go to the Backups tab and click Restore on the backup you want.
2. Choose what to restore: database and files, database only, or files only. If the backup included WordPress's own files and you restore files, you can tick to restore those too.
3. Leave Back up the site as it is now first ticked unless you made a backup very recently. The restore starts once that backup has passed its checks.
4. Type RESTORE and click Restore. If the database is restored, you are signed out and asked to sign in again, because the users and sign-ins now come from the backup.
5. Check the site. Then, on the Backups tab, click Keep the Restore or Roll Back. A reminder shows on every admin screen until you choose.

Restore from downloaded files

1. If the copy on the server is gone, open Restore from downloaded files on the Backups tab.
2. Choose every file of the downloaded backup at once: each zip file and manifest.json.
3. Click Upload Backup. The files are sent in small pieces, so large backups work on any host. When they arrive, the whole backup is checked; it appears in the list as Verified only if it passes. The list shows when the backup was made, with the upload time beneath it, and marks a backup this site did not sign as Not signed. An uploaded backup does not count as the site's latest backup.
4. Restore it as above. A backup this site made carries a signature only this site can create. Any other backup (one made before signing existed, after the database was lost, or on another site) can hold code that will run, so its code files are first checked with the malware scanner's signatures (anything flagged is listed under Details and in the restore panel), and restoring it asks for your password, and your authenticator code if you use one, and emails the alert recipients. The check finds known malware only; it does not prove a backup is safe. To refuse such backups entirely, turn off Accept uploaded backups this site did not make.

Good to know

Never changed by a restore: wp-config.php, Stack Guard itself, the backups and their settings, and the activity log, so the record of what happened on the site, including the restore, is never rewritten. wp-config.php stays inside the backup if you ever need it by hand.

The server's own add-on files in wp-content (object-cache.php, advanced-cache.php and db.php) are left as they are, like wp-config.php, because they belong to how this server is set up. If the backup holds a different copy, the restore says so.

After the swap, and after a Roll Back, the page caches of WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache, SiteGround and WP Fastest Cache are cleared when they are installed, so visitors do not see pages from before. A CDN such as Cloudflare is not cleared: purge it yourself.

A backup can only be restored onto the same site address it was made from. Moving a site to a new address is not supported yet.

Before it starts, the restore checks the backup files have not changed since they were verified, that there is enough free disk space, and, when the database is restored, that the site's database connection can load it (sites using a database add-on such as HyperDB or SQLite cannot). If any check fails, it stops with the reason.

If you do not choose Keep or Roll Back, the restore is kept automatically after 7 days and the old copy is removed.

If nobody can sign in to choose (for example the backup has different accounts or a different login address), whoever has command line access to the server can decide with WP-CLI: wp stack-guard restore status, then wp stack-guard restore keep or wp stack-guard restore rollback.

Keep and Roll Back need someone signed in with full access to Stack Guard. Restoring the database brings back the users, access levels and login address from the backup, so the restore panel warns when your account has no full access in the backup or the login address was different. Backups made before this check existed, and uploaded backups this site did not sign, cannot be checked, and the panel says so.

Files and folders that are not in the backup are moved aside too, so the site matches the backup. What the backup left out on purpose (your Leave out list, caches, files it could not read) is carried over into the restored site instead, so Keep never deletes it. Backups made before restore existed did not record what they left out, so for those, items not in the backup are left in place.

A restore can be cancelled while it unpacks and checks the backup. Once it starts swapping the site in, it finishes, and Roll Back is the way back. If the server stops part way, the restore carries on or puts everything back by itself, and visitors see the maintenance page for at most two minutes.

If Stack Guard is deleted while a restore waits for Keep or Roll Back, that counts as Keep and the old copy is removed, unless Keep data when the plugin is deleted is on, in which case everything waits until you reinstall and choose.

A folder that is a link to storage elsewhere (for example shared media storage) is left as it is. Its files are in the backup if you need them.

Tables in the same database that belong to another WordPress install are never restored or touched.

On a multisite network a database restore covers the whole network. If Stack Guard was active for the whole network, it stays active for the whole network afterwards, and network-wide cached values are cleared along with each site's.

With Test each backup by loading its database on, every new backup also loads its database copy into temporary tables, counts every row and removes them again. It is skipped for databases over 1 GB.

Which plan includes it

Restore, restore from downloaded files and the restore check after each backup are free. Restoring from Google Drive is coming to Pro.