Definition
What is disaster recovery for WordPress?
Disaster recovery for WordPress is the set of systems and decisions that keep a WordPress site serving visitors when its primary environment fails.
A traditional plan restores the site from a backup onto rebuilt infrastructure. That takes hours or days and loses everything since the last snapshot. A live replica approach keeps a second, current copy of the site running and isolated, so failover is a switch rather than a rebuild.
The two approaches answer different questions. A backup answers "can we get the data back?". A live replica answers "can visitors keep working while we deal with this?". For a WordPress site the business depends on, the second question is the one that costs money every minute it stays unanswered.
Why now
Why WordPress sites need disaster recovery now
Most WordPress disaster recovery plans are a backup plugin and a hope that the host is fine. The Namecheap meltdown in August 2026 showed what that plan is worth: sites, databases and the backups stored alongside them went offline together, and customers waited for someone else's cooling system to come back. A backup you cannot reach is not a recovery plan.
The facts that matter for a WordPress site today:
- WordPress powers a large share of the web, which makes its plugin and theme ecosystem the most attacked surface on the internet. Most WordPress compromises come through a plugin, not core.
- Hosting is the other single point of failure. In August 2026 a cooling failure at Namecheap's Phoenix data center took thousands of servers, and the sites on them, offline for the better part of a day. Read the post-mortem.
- PHP versions retire every year. A site pinned to an old PHP for plugin compatibility is running an unpatched runtime.
- Automatic updates help and hurt: they close vulnerabilities and they break sites at three in the morning.
Failure modes
Where WordPress sites actually fail
Disaster recovery planning tends to imagine fires and floods. Real WordPress outages are more mundane and more frequent. The failure modes that a plan for WordPress has to cover:
- A plugin or theme vulnerability exploited to deface the site, inject spam or install ransomware.
- A hosting outage that takes the site, its database and its backups offline together.
- An automatic update that breaks the theme or a critical plugin.
- A DNS or domain incident that makes a healthy site unreachable.
- The backup itself: stored on the same host or account, encrypted alongside production, or restored with the intrusion still inside it.
The replica
Why a live replica beats restoring WordPress from backup
Four things change when the site has a live, isolated copy instead of a snapshot on a shelf.
Zero recovery time, because nothing is recovered
The replica is already running. When the primary fails, visitors are switched to the copy in seconds. There is no rebuild, no restore window and no scramble to find the person who knows how the site was configured.
Zero data loss, because the copy is current
The replica follows the primary continuously rather than nightly. Changes made on the replica during an outage are captured and reconciled back when the primary returns.
Ransomware cannot follow
The replica is isolated from the primary's hosting account, network and credentials. An attacker who owns production has no path into the copy, and you never restore from a snapshot that might carry the infection with it.
The vendor's outage is not your outage
When a hosting provider, a cloud region or a dependency fails, the replica sits outside that blast radius. Visitors keep working while someone else fixes their problem.
How it works
How the Jestr replica works for a WordPress site
Jestr does not re-implement WordPress. It runs a copy of your actual site, kept current and kept apart.
Jestr builds a live copy of the site
Jestr replicates the WordPress site as it actually runs: the application, its data and its configuration, at the exact version and with the exact dependencies the primary uses. Nothing is re-implemented, so what visitors see on the replica is the site they know.
The copy stays current and stays isolated
The replica follows the primary continuously, at a known-good state, so an update that breaks production does not break the copy. It runs on Jestr's side of the outage with no shared credentials, network or identity, so a compromise of the primary stops at the primary.
When the primary fails, you switch
One action moves visitors to the replica. They open the same pages, sign in and keep working. Changes are captured on the replica. The switch works even when your own network is the thing that is down.
When the primary is back, you reconcile and switch back
Changes made on the replica are reconciled into the restored primary. You choose when to switch back. Nothing was lost and no backup was restored.
What the replica captures for WordPress
- Pages, posts, media, menus and the theme, so visitors see the same site on the replica.
- Forms, comments and logins, so the site keeps working rather than showing a static snapshot.
- The plugin set at a known-good state, so an update that breaks the primary does not break the replica.
- Isolation from the primary's hosting account, credentials and DNS, so a compromised site or a dead host cannot take the replica with it.
Side by side
Backup and restore vs a live WordPress replica
The same outage, handled two ways.
| Dimension | Traditional backup and restore | Live Jestr replica |
|---|---|---|
| Time until visitors are served again | Hours to days: provision, restore, reconfigure, test | Seconds: the replica is already running |
| Data lost | Everything since the last snapshot, often a full day | Nothing: the replica is current, and changes made during the outage are reconciled back |
| Ransomware | Backups often sit in the blast radius, and a restore can bring the infection back | The replica is isolated; you switch to it instead of restoring into the compromise |
| Vendor or hosting outage | You wait for the provider | The replica sits outside the provider's failure domain |
| Rehearsal | Rarely tested, because a full restore is disruptive and slow | Switching to the replica is routine and can be rehearsed any time |
| Who does the work at 3am | Your team, from a runbook that may be out of date | The switch is one action; the copy was built and kept current in advance |
FAQ
Frequently asked questions
What happened in the August 2026 Namecheap outage?
A cooling failure at a Phoenix data center forced Namecheap to power down more than 5,000 servers to protect them. Sites, email and hosting control panels on those servers were offline for most of a day. Our post-mortem covers the timeline and what it means for anyone whose site and backups live in one place.
My host takes daily backups. Is that not enough?
A daily backup means up to a day of lost changes, a restore that takes hours, and a copy that lives with the host. If the host is the thing that failed, the backup fails with it. The Jestr replica is already running somewhere else, so there is nothing to restore.
Does Jestr replace our WordPress backups?
No. Keep backups for archives, audits and long-term retention. Jestr replaces the part of the plan that backups are bad at: keeping the site available while the primary is down, without a restore window and without data loss.
Can visitors sign in and work on the replica, or is it a static copy?
It is the real WordPress site, not a snapshot of its pages. Logins, forms and integrations work. Changes made during the outage are captured and reconciled when the primary returns.
How is ransomware kept out of the replica?
The replica shares nothing with the primary that an attacker could use: no credentials, no network path, no hosting account. Replication is one-way and validated, so an encrypted or tampered primary does not propagate. You switch to a clean copy instead of restoring into the compromise.
How fast is failover?
Seconds. The replica is already running and current, so failover is the act of pointing visitors at it. There is no provisioning, restoring or reconfiguring in the critical path.
Does this work with managed WordPress hosting?
Yes. The replica sits outside the hosting provider, whoever it is. That is the point: when the host has a bad day, the site does not.