What it does
Restoring puts a chosen restore point back onto the live site from the dashboard — no SFTP, no manual file wrangling. A fresh safety backup of the site as it is right now is taken first and the restore waits for it; if that safety copy can't complete, the restore is abandoned and nothing on the site changes. That safety copy appears in the restore point list like any other, so a restore can itself be undone.
Everything slow — checksum verification, importing the database into a separate set of tables, unpacking files into a staging folder — happens before anything the live site reads is touched. The actual switch-over is a single atomic table rename plus a file move, so it's quick and it either fully happens or doesn't happen at all.
How to
- Open the site's Backups tab and pick a restore point from the list.
- Review the restore plan (what will change) and confirm.
- Wait for the safety backup to complete, then the restore proceeds through its stages automatically.
- Everyone is signed out afterward — the users, passwords and sessions all come from the restored database.
Limits & defaults
- What comes back:
wp-contentand the database. - What is left alone: files added since the backup (a restore lays the backup over what's there, it doesn't delete anything new); WordPress core files (never part of a backup); addresses stored inside post content (not rewritten).
- What is protected no matter what: the WPClientHub connector plugin's own folder and its stored connection details are never overwritten, the site keeps its current web address rather than the one recorded in the backup, and the connector is re-activated if the backup predates its installation — restoring never silently disconnects the site.
Permissions: starting a restore is owner/admin only, the same as connector self-update — a stricter bar than running a plain update batch.