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.
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.
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.
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. Restores to a staging environment first by default, so a failed restore does not leave you worse off than the original problem.
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.
Restore to staging first
The default path, because a restore that fails halfway on production leaves the site in neither state.
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.
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 better hosting or more frequent incremental capture.
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
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. Bring-your-own storage is available on request for agencies with existing arrangements or specific residency requirements.
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.