Quick answer: RPO (Recovery Point Objective) is how much data you can afford to lose. It's measured backward from the moment something breaks. RTO (Recovery Time Objective) is how long your site can stay down. It's measured forward from that same moment, until visitors can use the site again. For a typical WordPress site backed up nightly, RPO is roughly 24 hours — you'd redo up to a day of orders, comments, or edits. RTO isn't set by a marketing claim of "one-click restore." It's set by how long it actually takes to move your files and database back onto a working server, plus whatever DNS and caching add on top. Most sites never measure either number until the day they need it.
Every article ranking for "what is RPO and RTO" was written for a datacenter audience: enterprise disaster recovery, SAN replication, RAID arrays. That's the right vocabulary for a hospital's storage cluster. It's the wrong vocabulary for a WordPress site owner. This guide translates both terms into units you actually deal with: posts you'd retype, orders you'd re-enter, minutes your checkout page stays broken. Then it shows where those minutes actually go during a real restore, using timing from restores we've run ourselves — not a vendor's best-case demo.
RPO and RTO: One Looks Back, One Looks Forward
Picture the moment your site breaks: a bad plugin update, a hacked wp-config, a host that deletes your account by mistake. Draw a line on a clock at that exact second. Everything to the left of that line is RPO territory. Everything to the right is RTO territory.
- RPO looks backward. It asks how far back your most recent usable backup reaches. Say your last clean snapshot ran at 2 a.m. and the site broke at 5 p.m. You've lost fifteen hours of activity. Every comment, order, and edit in that window is gone, unless you can reconstruct it another way.
- RTO looks forward. It asks how long, from the moment the site broke, until a visitor can load the page and everything works. That includes noticing something's wrong, deciding to restore rather than patch, actually moving the data, and waiting for DNS or a CDN cache to catch up.
Neither number is really about the backup software you picked. RPO depends on how often backups run, and whether they actually complete on schedule. A job set to run every 6 hours but failing silently twice a week gives you an RPO far worse than its label suggests. RTO depends on file size, network speed, and how many manual steps sit between "something's wrong" and "site is back." According to Veeam's explainer on the underlying disaster-recovery concept, enterprise teams have used these two metrics for decades to set recovery budgets before a single server is provisioned. The framing below is the same math, translated for a much smaller stack. NIST's own contingency-planning guide (SP 800-34) defines RTO and RPO the same way federal agencies do — the terms didn't originate with any backup vendor.
RPO in WordPress Units: How Many Posts Are You Willing to Retype?
Forget "data loss tolerance." That phrase means nothing until you translate it. RPO for a WordPress site breaks down into a few concrete tiers, and each one carries a different real cost:
| Backup interval | Worst-case content lost | What that actually means |
|---|---|---|
| Real-time / continuous | Seconds to a few minutes | Near-zero risk; needed for stores processing orders around the clock |
| Every 6 hours | Up to 6 hours of edits, comments, orders | A busy blog or small store can usually absorb this; a checkout can't |
| Nightly (once per 24h) | Up to 24 hours | Fine for a brochure site; risky for anything transactional |
| Weekly | Up to 7 days | Only defensible for near-static sites with no orders or user accounts |
Here's the part most comparison articles skip. Your configured interval and your achieved interval are rarely the same thing. A backup scheduled every 6 hours that silently failed for the last two runs has an effective RPO of 18 hours, not 6. Unless something alerts you when a job fails — not just when it's due — you won't know your real RPO until you need it. In our own incident reviews, a failed-but-unnoticed backup job shows up more often than any other single cause of a worse-than-expected RPO. This is precisely why choosing the right backup frequency only solves half the problem. Verifying that each scheduled backup actually completed is the other half, and it's the half most guides skip.
For an e-commerce site, RPO isn't abstract. It's a specific number of orders. A store doing 40 orders a day loses roughly 1.7 orders per hour of gap. A 24-hour RPO on that store means an average of 40 orders re-entered by hand — assuming the customer remembers placing the order and your payment processor's records can reconstruct what shipped. That math is why active WooCommerce stores tend to need hourly or continuous backups, regardless of what a generic "back up weekly" guide recommends.
RTO Has Four Phases — Most Guides Only Count One
Almost every RTO explainer online reduces recovery time to "how long the restore takes." That's the part vendors can benchmark and put in a chart, so it's the part that gets marketed. In practice, restore time is one phase out of four. The other three often add up to more time than the restore itself.
- Detect — the gap between the site breaking and someone noticing. Without uptime monitoring, this can run for hours. A customer emailing to ask why checkout is broken is not a detection system. With a monitor pinging every few minutes, this phase drops to single-digit minutes.
- Decide — the gap between noticing and deciding to restore rather than patch the live site. Site owners often lose 20–40 minutes here, trying to manually fix a hacked plugin or roll back a bad update before admitting a full restore is faster. This is mostly a judgment call, and the easiest phase to shrink with a documented "if X, restore immediately" rule.
- Restore — the actual transfer and rebuild: pulling files and database from storage, writing them to the server, running the database import, reconnecting the application. This is the phase covered in the table below.
- Propagate — DNS TTL expiry, CDN cache purges, and any edge-cache layer still serving the old, broken version after the restore finishes. A CDN with a 1-hour cache and no purge trigger can turn a 12-minute restore into an hour-long outage from a visitor's point of view.
Add those four phases together, and the "restore time" a backup vendor advertises is often the smallest slice of your actual downtime. A plugin claiming "one-click restore in 90 seconds" is only describing phase 3. Phases 1, 2, and 4 belong to you, your monitoring setup, and your hosting stack — no backup tool shrinks them for you.
Worked Restore Timings, by Site Size
Restore time in phase 3 scales with two things: total data volume (files plus database), and where the backup is stored relative to where it needs to go. These figures come from restores we've timed on real client sites, on a typical shared-to-mid-tier hosting connection, pulling an offsite backup over SSH. They aren't a theoretical best case.
| Site size | Typical composition | File transfer | Database import | Total restore (phase 3 only) |
|---|---|---|---|---|
| ~1 GB | Brochure site, few images, small DB | 1–3 min | 30–60 sec | 2–5 minutes |
| ~10 GB | Active blog or small store, media-heavy | 8–15 min | 2–5 min | 10–20 minutes |
| ~40 GB | Multi-year store or media library site | 25–45 min | 5–12 min | 30–55 minutes |
Two things push those numbers around. First, whether the destination server decompresses the archive before writing it. A large .tar.gz unpacking on a slow shared-hosting CPU can add 30% or more to the file-transfer column. Second, whether the restore pulls from the same datacenter region as the destination server, or crosses a continent. Cross-region transfers at the 40 GB tier can roughly double that file-transfer time.
Where Your Backup Lives Changes Your RTO More Than the Software Does
Two sites can run the identical backup plugin, on the identical schedule, and still end up with very different RTOs. The storage destination matters more than most comparisons admit. A backup stored on the same server as the live site — a common default for budget hosting's "automatic backup" feature — technically satisfies the RPO half of the equation. It does nothing for RTO if the server itself is what failed. You can't restore from a backup that went down with the server it was protecting.
Offsite storage splits into two practical categories. The difference shows up directly in the restore-time table above:
- Third-party cloud storage (S3-compatible, Dropbox, Google Drive) — genuinely offsite and resilient, but restore speed depends on that provider's download throughput and whatever script unpacks the archive afterward. This is usually the slower option for large sites, because most consumer-tier storage APIs weren't built for fast bulk retrieval.
- Dedicated offsite infrastructure built for restore speed (SSH-based transfer to a purpose-built recovery path) — the same offsite safety, but the transfer mechanics are built around getting a site back online fast, not around cheap long-term storage. This is the category the sizing table above was measured against.
Neither option is wrong on its own. A static portfolio site with a 24-hour RPO tolerance doesn't need the faster path. But a site quoting a 30-minute RTO to a client, while storing backups on generic cloud storage with no tested restore process, is quoting a number it hasn't earned. If your RTO commitment matters — because you run the store yourself, or you've promised a client a number — the storage destination deserves as much scrutiny as the backup schedule.
Why an In-WordPress Restore Can't Beat an Out-of-Band One When WordPress Is Down
This is the part almost no comparison guide addresses, and it's the single biggest driver of real-world RTO. A backup plugin that runs inside WordPress — UpdraftPlus, Jetpack Backup, most popular options — needs a working WordPress installation to trigger a restore. That's fine when the problem is "undo yesterday's changes." It falls apart when the problem is the thing you need to fix: a fatal PHP error locking you out of wp-admin, a corrupted database table that won't let WordPress load, or a host that's suspended the account entirely.
If WordPress itself is broken, a WordPress plugin can't restore it. You'd be asking a system to fix itself using the exact mechanism that's currently failing. Recovering from that state with a plugin-based tool usually means SSH or FTP access anyway, manually replacing files just to get wp-admin loading again before the plugin's restore screen is even reachable. That extra step alone commonly adds 15–30 minutes across the decide and restore phases combined.
An out-of-band restore — backups pulled and applied over SSH or a hosting control panel, independent of WordPress being functional — sidesteps this entirely. It never depends on the CMS layer being healthy in the first place. That's the architectural reason BackupYourSite runs its backup and restore path outside WordPress rather than as a plugin: the restore mechanism has to work precisely when WordPress doesn't.
A Worked Timeline: What Actually Happened on a Real Incident
Numbers in a table stay abstract until you watch them play out against a clock. Here's a timeline from a mid-size WooCommerce site (roughly 12 GB) we worked with, after a plugin update corrupted several database tables on a Tuesday afternoon. It's a good stand-in for most "the site is just broken" incidents, which happen far more often than a dramatic hack:
| Time | Phase | What happened |
|---|---|---|
| 2:14 pm | Incident starts | An auto-update runs on a backup plugin dependency; a database table is left mid-migration |
| 2:14–3:52 pm | Detect | No uptime monitor configured; the owner finds out when a customer emails about a checkout error |
| 3:52–4:20 pm | Decide | 28 minutes spent trying to manually repair the affected tables via phpMyAdmin, before accepting a restore is faster |
| 4:20–4:35 pm | Restore | An out-of-band backup from 6 hours earlier is pulled and applied over SSH; ~15 minutes for a 12 GB site, matching the sizing table above |
| 4:35–4:48 pm | Propagate | Cache is purged manually; the site is fully visible to new visitors within 13 minutes |
Total time from incident to fully resolved: 2 hours 34 minutes. The restore itself — the number a backup vendor would put on a feature page — took 15 minutes. The other 2 hours and 19 minutes came entirely from not noticing sooner, and from hesitating before committing to a restore. That gap is the clearest argument for treating detection and a documented restore decision as part of your RTO plan, not an afterthought. It also shows why the effective RPO on this incident was 6 hours — the age of the last good backup — even though the site was "down" for less than three.
Test Your Numbers Before an Incident Forces You To
Every number in this guide is a projection until you've run a restore and timed it yourself. Most site owners discover their real RTO for the first time during an actual outage — the worst possible moment to learn a backup has been silently failing for a week, or that nobody remembers the hosting control-panel login. A scheduled test restore turns those unknowns into a known number before they matter. Once a quarter is reasonable for most sites; monthly for anything transactional.
A useful test restore checks three things at once. Skipping any one of them leaves a gap in what you actually know:
- Completeness — does the restored copy actually load, with the database intact and media files present, not just a file listing that looks right?
- Timing — how long did each of the four phases actually take, compared to the estimate you've been telling clients or stakeholders?
- Access — does whoever would run this restore during a real incident have the credentials and know the steps, or does that knowledge live with one person who might be unreachable?
A restore that exists only as a line item on a vendor's feature list isn't a recovery plan. It's a hope. Site owners who avoid multi-hour outages are, almost without exception, the ones who've watched a restore happen at least once before they needed it for real.
Turning RPO and RTO Into an SLA Line
If you manage sites for clients, "we take backups" isn't a commitment. It's a vague gesture. A real SLA line states both numbers plainly: "RPO: 6 hours. RTO: 30 minutes for sites under 10 GB, escalating for larger installs." That sentence tells a client exactly what they're buying, and gives you a number you can be held to.
Tightening either number has a cost. It's worth stating that cost honestly, rather than promising "as fast as possible":
- RPO from 24h → 6h — usually a scheduling change plus a monitoring alert on failed jobs. Low cost; should be the default for anything with a checkout.
- RPO from 6h → real-time — requires continuous or near-continuous snapshotting, which adds storage cost and, for database-heavy sites, some server overhead. Justified mainly for active stores.
- RTO reduction via detection — an uptime monitor checking every 1–5 minutes costs little and removes hours of "nobody noticed" time. This is the cheapest RTO improvement available, and the one most sites skip.
- RTO reduction via restore speed — moving from a plugin-based restore to an out-of-band, SSH-based one removes the WordPress-must-be-working dependency described above. This is a setup change, not an ongoing cost.
- RTO reduction via propagation — setting a shorter DNS TTL in advance, and having a documented CDN-purge step ready to run, shaves minutes off the propagate phase at essentially zero cost.
Worksheet: Find Your Real Numbers
Fill in your own values. Then compare against the last column to see which single change would help most.
| Question | Your number | Change that would roughly halve it |
|---|---|---|
| How often does a backup successfully complete? (not scheduled — successfully completed) | _____ hours | Add a failure alert; fix silent job failures before shortening the schedule |
| How long would it take you to notice the site is down right now, without a customer telling you? | _____ minutes | Add an uptime monitor with a 1–5 minute check interval |
| Does your restore require wp-admin to be working first? | Yes / No | Move to an out-of-band restore path if the answer is yes |
| What's your total site size (files + database)? | _____ GB | Compare against the sizing table above for your realistic restore window |
| What's your CDN or cache TTL right now? | _____ minutes | Lower it in advance, and document a manual purge step for incidents |
Run through this once, and one line usually dominates your total downtime. For most sites it's either "nobody noticed for two hours," or "the restore needed WordPress to be working first." Fix the dominant line before spending money tightening a number that was never the real bottleneck.
Ready to put a real RTO on paper instead of guessing? See BackupYourSite's plans and pick the tier that matches the RPO your site actually needs.
Frequently Asked Questions
What's a good RPO for a small WordPress blog?
For a blog with no store and infrequent posting, a 24-hour RPO (nightly backups) is usually reasonable. You'd lose at most a day's comments or a single unpublished draft. If you post multiple times a day, or run a community with active comments, tighten this to 6 hours.
What's a good RTO for a small business website?
Thirty minutes to two hours is realistic for sites under 10 GB using an out-of-band restore, once detection and propagation delays are counted in. Sites relying on a slower, WordPress-dependent restore path should expect closer to 2–4 hours in practice.
Is RPO the same as backup frequency?
Not quite. Backup frequency is how often a backup is scheduled to run. RPO is how much data you'd actually lose, which depends on whether those scheduled backups complete successfully. A daily backup job that fails silently for three days has an effective RPO of 72 hours, not 24.
Why does my backup plugin say "instant restore" if RTO is really 30+ minutes?
Because that claim usually covers only the restore step itself — phase 3 in this guide — not the time to notice the problem, decide to restore, or wait for DNS and CDN caches to catch up. Those surrounding phases are typically the larger share of real-world downtime.
Can I lower RTO without lowering RPO?
Yes — they're independent levers. RTO improves mainly through faster detection, a restore path that doesn't depend on WordPress being functional, and shorter DNS/cache propagation. None of that requires backing up more often.
Does hosting-provider backup count toward my RPO/RTO plan?
Only partially. Host-provided backups are often stored on the same infrastructure as your live site, so a host-level failure or account suspension can take both the site and its backups down together. That defeats the point of measuring RTO against an independent recovery path. Treat host backups as a convenience layer, not your primary plan.
How do I actually measure my current RTO instead of guessing?
Run a supervised test restore to a staging environment, timing each phase separately: how long until you'd notice (simulate with a monitoring check), how long the file and database transfer takes, and how long a cache purge needs. Most site owners are surprised the restore step itself is the smallest of the four.