A backup is a hypothesis until you have restored it
Most WordPress backups have never been tested. The failure is discovered during an incident, which is the worst possible moment to learn something new about your infrastructure.
Free during early access. No credit card required.
Updated
How do you restore a WordPress site?
You restore a WordPress site by putting back a backup of its database, its files, or both, taken at a point before the problem started. The right restore depends on the failure: a broken plugin needs its files back, a mangled setting needs the database, and a hacked site needs a copy from before the first sign of the hack.
WPCentrify restores any connected WordPress site from its restore points in a few clicks: the whole site, only the database, or chosen files and folders. A running restore shows how far it has got and how long is left, and if a site is hacked WPCentrify points you to the last backup taken before the first sign of the hack. Our guide on how to restore a WordPress backup safely covers the checks to make first.
WPCentrify restore at a glance
- Restore the whole site, only the database, or chosen files and folders.
- Progress shown inside each table and file, with an estimate of the time left.
- For a hacked site, the last backup from before the first sign of the hack is offered first.
- A plugin or theme update can be put back on its own, without restoring the rest of the site.
- A file the host will not let WordPress write is named and left as it is, instead of ending the restore.
Why backups fail silently
Almost every WordPress site has a backup running. A considerably smaller number have a backup that would actually restore. The gap between those two facts is where most catastrophic data loss lives. Our WordPress backup guide covers how to set backups up so they are worth restoring.
The failure modes are consistent and boring. The plugin hit a PHP timeout partway through a large database and wrote an incomplete archive. The destination filled up. Credentials expired and the schedule silently stopped after a plugin conflict. Or the backup has been running perfectly for two years to a folder on the same server that has now been wiped.
None of these produce an alert, because from the backup tool's perspective the job completed. The status is green. You find out during recovery, when the archive will not extract or the database import fails halfway through.
What a real recovery capability requires
- Backups stored in a different failure domain from the site
- Incremental capture so large sites do not time out
- Scheduled restore testing that actually boots the copy
- Granular recovery, not only whole-site rollback
- A measured recovery window you can quote honestly
- Retention deep enough for a slow-burning compromise
WordPress disaster-recovery plan: paths for different failures
Different problems need different restores. Rolling back an entire site because one plugin update failed is a common and costly overreaction.
Files only
The right response to a failed plugin or theme update. Restores code while leaving the database untouched, so posts, users and orders created since the backup are all preserved.
Database only
The right response to a bad import, corrupted content or a plugin that mangled its settings. Restores content and configuration while leaving files alone, which also makes it the way back from a database cleanup that removed more than you expected.
Granular recovery
A single plugin directory, a single table, or a specific set of files. Usually enough, and far less disruptive than a full restore.
Full restore to a point in time
For serious compromise or catastrophic failure.
Recovery capabilities
Scheduled restore testing
Backups are restored to an isolated environment on a schedule and confirmed to boot, so backup status is evidence rather than assumption.
Measured recovery window
How long a restore actually takes for each site, measured rather than estimated, so the number you quote clients is real.
Point-in-time selection
Restore to a specific moment, with the gap that will be lost shown before you confirm.
Order-aware warnings
On stores, the number of orders falling in the restore gap is surfaced before you proceed, not discovered afterwards.
Recovery evidence
Every restore and restore test recorded, which is what a client asks for after an incident.
Recovery time is a commercial number
Care plans routinely promise that sites are backed up. Very few promise how quickly a site can be recovered, because most agencies do not know, and quoting a number you have not measured is a promise you may not keep.
Measured recovery windows change that conversation. Knowing that a particular site restores in eleven minutes, because it has been tested repeatedly, lets you write a recovery target into a care plan and defend it. It also lets you charge appropriately for tighter targets on sites that need them. None of it works without incremental encrypted backups stored off-site underneath.
It also surfaces the sites where recovery is unacceptably slow, usually because the site is very large or the hosting is very poor. Those are worth knowing about before an incident rather than during one, and they are often a straightforward upsell conversation about capturing more frequent incrementals.
Backup practices that fail under pressure
- Backups stored on the same server as the site
- Full backups only, timing out on large databases
- Retention too short to predate a slow compromise
- No test restore ever performed
- Recovery time never measured, only estimated
Related
Questions about restore and recovery
Configurable per site. Monthly for business-critical sites and quarterly for everything else is a reasonable baseline. What matters more than the frequency is that it happens at all, since an untested backup is a hypothesis rather than a safety net.
Yes. Granular recovery lets you restore specific files, directories or database tables rather than the whole site. After a failed plugin update this is almost always the correct action, and it preserves everything created since the backup.
Anything created after the backup point is lost, which on a store means orders. The number of orders falling in the gap is shown before you confirm, so it is a decision rather than a discovery. Export them first if you need to reconcile.
It depends on site size and hosting, which is exactly why we measure it per site rather than quoting a general figure. Most small business sites restore in under fifteen minutes; large stores with big databases take longer. Your measured figure is shown against each site.
Encrypted, off-site, in a different failure domain from the site itself. Keeping backups in your own S3-compatible storage, for agencies with existing arrangements or specific residency requirements, is planned.
Pick a restore point from before the problem started, choose whether to restore the database, the files or both, and run the restore. In WPCentrify you choose the restore point and what to restore from the dashboard, and the restore runs without you having to upload anything to the server.
Yes. WPCentrify can restore only the database, only chosen files and folders, or the whole site, so you do not have to roll an entire site back to fix one thing.
Contain it, find when it was first changed, restore a clean copy from before that moment, then close the way in: update everything, change passwords and remove unknown administrators. WPCentrify shows a hacked site's timeline, offers the last backup from before the first sign of the hack, and can sign everybody out of the site in one step.
Prove your backups work before you need them
Scheduled restore testing, granular recovery, and a measured recovery window for every site you manage.
Free during early access. No credit card required.