Most people with a WordPress site have a backup somewhere. Far fewer have ever restored one, which means far fewer know whether the thing they are relying on works.
Restoring is not a single operation. It is a decision about scope, a decision about which point in time, and an acceptance of whatever happened in between. Getting those right is most of the job. The button is the easy part.
Stop and answer three questions first
The instinct in an outage is to restore immediately. Ten minutes of diagnosis usually saves hours, because a restore is destructive: it replaces what is on the server, including anything good that happened since.
What actually broke? Match the scope to the fault. A plugin update that broke a layout does not need the uploads directory replaced. A defaced home page does not need last night's orders rolled back. Restoring more than necessary is how a small problem becomes data loss.
When did it break? You want the last backup before the problem, which is not always the most recent backup. This is where people go wrong most often: restoring the newest available copy, which already contains the fault. If a bad import ran on Tuesday and you noticed Thursday, Wednesday's backup is useless.
What will be lost? Everything created between the backup and now. On a blog, a couple of posts. On a store, real orders belonging to real customers who will contact you about them. Quantify it before you start, and if it is orders, export them first. A restore that loses revenue you could have exported in five minutes is a self-inflicted second incident.
Choosing the scope
Database only. Replaces content, settings, and users; leaves files untouched. Use it for data problems: deleted content, a bad bulk edit, corrupted settings, a botched import. Fast, and preserves media uploaded since the backup.
Files only. Replaces the file system; leaves the database alone. Use it for file problems: a broken theme update, corrupted plugin files, injected code. Preserves everything published or ordered since the backup, which is usually what you want.
Full restore. Both. Use it for a compromise, a catastrophic failure, or a move to a new server, where you need a coherent known-good state rather than a mix.
The distinction matters because database and files drift apart. Restoring a database from last week alongside today's files can leave the database referencing plugin versions that are no longer on disk, or vice versa. Partial restores are the right tool often, but "which half is wrong" is a question worth answering deliberately.
Performing a full restore
- Select the backup. The Backups tab lists every available backup with timestamp, size, and type. Pick by the reasoning above, not by recency.
- Choose the scope. Database, files, or both.
- Confirm. WPMgr requires explicit confirmation before overwriting live data, and shows what will be replaced and when the selected backup was taken. Read the timestamp. This is the last point at which a wrong choice is cheap.
- Let it run. The job runs asynchronously with progress reported, so a large restore does not depend on a browser tab staying open.
- Verify properly. Not just that the home page loads.
That last step deserves expansion, because "the site is back" is a conclusion people reach far too quickly.
Verifying a restore
Check, in roughly this order: the home page and one deep page render; the newest content is present and matches the timestamp you expected; you can log in; a form or checkout completes end to end; images load rather than 404, which is the classic sign that files and database disagree; and permalinks resolve, since a stale rewrite state produces a working home page and 404s everywhere else.
On a store, confirm order numbering continues from the right place. On a membership site, confirm one real account still has access.
If the site was behind a cache or CDN, purge it. A restore that appears to have done nothing is very often a cache serving the old page.
Test on staging when the stakes justify it
For a significant restore on a site that matters, restore to staging first. It costs time you feel you do not have, and it answers questions you otherwise answer on production: is this backup actually valid, does the data you need exist inside it, and how long does the process take.
That third answer is worth having in advance. Restore duration is dominated by file count and database size, and people routinely underestimate it by an order of magnitude when planning a maintenance window.
WPMgr can restore any backup to any site in the fleet, so a production backup can be restored onto a staging site using the same mechanism you would use in the real event. Rehearsing the actual path, rather than a parallel one, is the point.
Restoring to a different domain
Restoring to staging, a new host, or a rebuilt server means the site's URL changes, and WordPress stores its URL in a great many places. This is where most manual restores go wrong.
A naive find and replace across the SQL dump will corrupt the database. WordPress stores plugin and theme settings as PHP serialized data, and serialized strings carry their own length prefix:
s:19:"https://example.com";
Replace that URL with a longer or shorter one and the 19 no longer matches. PHP fails to unserialize the value and the setting silently becomes empty. The visible symptom is a site that loads with its theme options gone, widgets missing, or a page builder rendering blank, and the cause is invisible because the database looks fine.
The fix is a serialization-aware replacement that recalculates the lengths, which every competent migration tool does and sed does not. If you are doing this by hand, use WP-CLI's search-replace, which handles serialized data correctly.
Also expect to update: the siteurl and home options, hardcoded URLs in post content and custom fields, and any absolute path baked into a cache configuration. And set the staging copy to discourage search engines, because the reliable way to discover a staging restore went unnoticed is to find it ranking against production.
When a restore goes wrong mid-flight
A restore is destructive by definition, which means a restore that fails partway leaves a site in a state that is neither the old one nor the new one.
The scenarios worth anticipating: the process times out on a large uploads directory, leaving files half replaced; the disk fills, because a restore can transiently need space for both copies; the database import fails midway, leaving some tables from the backup and some from before; or a PHP or MySQL version on the new server rejects something the dump contains.
Two things make this survivable. Take a backup of the current state immediately before restoring, even when the current state is broken, so a failed restore has somewhere to return to rather than leaving you with nothing. And prefer a restore process that stages then swaps rather than overwriting in place, so a failure leaves the original intact.
Practically: check free disk space before starting a large restore, and confirm the target PHP and MySQL versions are not older than the source. Restoring a database dumped from a newer MySQL onto an older one fails in ways that are tedious to unpick.
Restoring after a compromise is different
A standard restore assumes the backup is clean. After a security incident that assumption is exactly what is in question.
Compromises are usually discovered well after they begin. If the intrusion predates your backups, every copy contains the backdoor, and restoring reinstates it. Restoring further back trades data for confidence, which is a real trade and sometimes the right one.
The sequence:
- Preserve the current state before changing anything. Take a backup of the compromised site as evidence. If you clean first, you lose the ability to work out what happened.
- Find the entry point. Restoring without closing the door produces a site that is compromised again, often within hours. Check access logs around the first known bad change, review recently installed plugins, and audit administrator accounts.
- Restore from a backup you have reason to believe predates the intrusion, which may not be the newest.
- Rotate every credential. Admin passwords, application passwords, the database password in
wp-config.php, API keys for connected services, and the hosting account itself. Application passwords deserve specific attention because they bypass two-factor authentication and survive a password reset. - Scan the restored site. Run file integrity monitoring against known-good checksums and a vulnerability scan to identify what was likely exploited.
- Patch before going back online. Update the vulnerable component, or remove it if it is abandoned.
- Check the database and scheduled tasks, not only the files. Injected admin users, malicious entries in options, and a cron task that re-downloads a payload all survive a files-only restore untouched. This is the usual reason a site "gets hacked again" days later.
The restore you will actually perform
Disasters are rare. The common case is a plugin update that broke something at eleven in the morning, and the fix is to go back fifteen minutes.
This is why pre-update snapshots matter more than any other part of a backup strategy. WPMgr takes a full backup immediately before every update, so a broken update is a one-click rollback to the state a moment before, with nothing lost in between and no decision to make about which point in time.
If you set up nothing else after reading this, set up automatic snapshots before updates. It converts the most frequent way WordPress sites break from an incident into an undo.
For the feature detail see the Backups and restore page. For choosing frequency, retention, and storage, see the backup strategy guide and the WordPress backups solution guide.