Part of the guide: Back up your WordPress site before a big update
Part of the guide: How to automate off-site WordPress backups to Google Drive
Part of the guide: How to restore a WordPress site without phpMyAdmin or FTP
Since version 2.3.0, BackupEase restores your site from the plugin itself. You pick a backup, choose whether to put back the database, the files, or both, and press a button. No phpMyAdmin, no FTP client, no downloading archives to your laptop. This page explains what the Restore tab does, what it deliberately does not touch, and how to undo a restore you did not want. For the click-by-click version, see How to Restore a WordPress Site Without phpMyAdmin or FTP.
Anything created since the backup was taken is gone once the restore completes. Posts, orders, form entries, uploaded media. If your site still loads, take a fresh backup first so you have a way back to today. The Undo described below gives you 24 hours of grace, but a fresh backup is the thing that has no expiry.
Where it lives
Two places, and they do the same thing:
- BackupEase › Restore lists every backup you can restore from, under Available Backups.
- The Restore button on any row in Recent Backups, on the Dashboard, jumps straight to the same confirmation step for that backup.
The list holds your 30 most recent completed backups. A backup appears if at least one of its two parts is still reachable, either on your own server or in cloud storage. Failed and cancelled backups never appear.
What you can restore
After you press Restore, a Confirm Restore card appears with two checkboxes, both ticked:
| Option | What it puts back | When to untick it |
|---|---|---|
| Restore the database | Every table in the backup: posts, users, settings, orders. | A plugin or theme update broke the site but your content is fine. Restore files only. |
| Restore the files | Themes, plugins, uploads and WordPress core from the archive. | You need yesterday's content back but want to keep the code you have deployed today. |
Unticking both is refused. If the backup only ever contained one of the two, only that one is offered.
Test a backup without touching your site
Next to Restore on every backup row is a Test button. It answers one question: would this backup actually restore?
Testing runs the real restore machinery. The database dump is read and imported in full, into a separate set of temporary tables sitting alongside your live ones. The import is then inspected, the temporary tables are thrown away, and you get This backup can be restored. Your site is not modified at any point, and the files half is skipped entirely.
A backup that cannot be read is worse than no backup, because you do not find out until the day you need it. Testing a recent backup once a month costs you a few minutes and tells you whether the last month of backups were real.
How a restore protects itself
The design principle is that nothing live changes until the very end, and everything that does change can be reversed.
-
The database goes in beside your site, not over it
The dump is imported into tables with a temporary
bkrs_prefix. This is the long phase, and the one a shared host is most likely to kill, and it runs entirely alongside your live tables. A failure here changes nothing at all. - The import is checked before it is trusted BackupEase reads the imported settings table and confirms it is not empty, that the table set is coherent, and that the backup came from this site's address. A backup holding some but not all of the tables WordPress needs is refused here, before anything live has moved.
- Files are written, with a record of every change Files cannot be staged the way tables can, because a staged copy would need as much free disk again as the site. So they are written in place, but every file that gets replaced is moved into a rollback folder first, and every file that gets created is added to a list. Plugins and themes are written last, immediately before the database swap, to keep the window where new code runs against the old database as short as possible.
-
The database swaps in one statement
A single
RENAME TABLEputs the imported tables live. MySQL applies it atomically, so there is no moment where half your tables are from the backup. The tables it replaces are renamed aside underbkold_rather than dropped. - The site is put back in order Caches are flushed, BackupEase is re-enabled, permalinks are rebuilt, and your login session is carried across so you are not logged out mid-restore.
If any step after the file phase begins fails, BackupEase reverses both halves on its own: the old tables come back and the moved-aside files are put back. You are left with the site you had before you pressed the button. That is what makes "a restore that dies halfway leaves your site as it was" a description of the code rather than a hope.
What a restore never overwrites
Some files describe the server rather than the site, and restoring them from another machine's backup would break the site rather than fix it. These are always skipped:
wp-config.php,.htaccessand.user.ini- Drop-ins such as
object-cache.phpandadvanced-cache.php, anddebug.log - BackupEase and BackupEase Pro themselves, and the BackupEase storage folder inside
wp-content/uploads
Your BackupEase settings, your schedules and your storage connections also survive a restore, so the plugin does not come back configured the way it was months ago.
Undo, for 24 hours
When a restore finishes you get two buttons:
| Button | What happens |
|---|---|
| Keep this restore | The parked tables and the rollback folder are cleared away immediately. The restore becomes permanent. |
| Undo the restore | The database is swapped back, the files the restore added are removed, and the files it replaced are put back. You end on Your site is back to how it was before the restore. |
If you press neither, the undo data is kept for 24 hours and then cleaned up automatically. Undo is in the free plugin. It is not a paid feature.
Undo works through the same tens of thousands of files the restore did, so on a big site it takes a while. If it is interrupted, the restore goes back to its finished state with the Undo button still available, and each stage is safe to repeat. Press Undo again and it picks up rather than starting over.
Restoring a backup held in cloud storage
You do not have to download anything by hand. If the only copy of a backup is in Google Drive, pick it in the Restore tab and BackupEase fetches it for you, in pieces, resuming where it left off if a piece fails. That is what lets a very large backup come down on a shared host without exhausting memory or hitting the execution time limit.
BackupEase Pro extends the same path to FTP, SFTP, OneDrive, Dropbox and S3-compatible storage, fetched the same way.
Limits worth knowing before you need them
| Situation | What happens |
|---|---|
| The backup was taken at a different web address | Free refuses it, with both addresses named, before anything changes. BackupEase Pro 2.1 or newer allows it and rewrites the addresses as it restores. See the section below. |
| The server cannot open zip files | Files cannot be restored. The database still can, and BackupEase says so rather than failing silently. |
| A backup is running | The restore is refused until it finishes, and the reverse is also true. They read and write the same files and tables. |
| Multisite | A restore puts back the whole network from one archive. There is no per-subsite restore. |
Restoring onto a different web address
A backup carries the address it was taken at inside the database, in the settings table, in every post that links to an image, and inside serialized data that other plugins have stored. Put that backup on a site at a different address without changing any of it and you get a site that redirects to the old domain, or one whose media all 404.
The free plugin refuses this case outright, naming both addresses, before anything on your site has changed. BackupEase Pro 2.1 or newer allows it and does the rewriting for you.
The rewrite runs after the import and before the swap, so it works on the temporary tables while your live site is still untouched. It walks every text column of every imported table, not just the ones WordPress itself defines, so a custom table belonging to another plugin is covered too. Values that can hold serialized data, which is to say options and metadata, are unpacked, rewritten inside, and repacked, so the byte counts stay valid and nothing turns into an unreadable blob. Nested serialization inside serialization is handled the same way. Like the rest of a restore, it runs in batches against a deadline and picks up where it stopped, so a large site does not need one long request.
A site records one spelling of its own address, but the database holds the others. A link written before the certificate was installed still says http. A theme option pasted out of a browser bar carries the www. the saved address leaves off. Older themes store an address with no protocol at all. The rewrite covers all of them: http and https, with and without www., and the protocol-less form, which stays protocol-less on the way out so it keeps working on both schemes. A backup of a site installed in a subdirectory keeps its path through the same replacement.
Addresses that are not stored as plain text are covered as well. A page builder that keeps its settings as JSON writes slashes escaped, as https:\/\/old-site.com, which is where most of the addresses on an Elementor-built page actually live. An address stored inside another address, a saved redirect target or a return URL, is percent-encoded as https%3A%2F%2Fold-site.com, in either letter case. A plain search and replace misses all of these and leaves a site that looks fine until you open the page builder.
How long it takes
A restore is paced by the same aggressiveness setting as a backup, under BackupEase › Settings. It runs in resumable slices and carries itself forward without your browser, so closing the tab does not stop it. Reopening the Restore tab shows the run still in progress. If your host is constrained, a lower aggressiveness makes each slice smaller and the whole run longer, but far more likely to finish.