Every conversation about backup and disaster recovery eventually lands on two acronyms, and they’re worth two minutes of plain English, because between them they decide almost everything: what backup system you should buy, what it should cost, and what your worst day will actually feel like.

RPO — recovery point objective — is how much work you can afford to lose. If your systems failed right now, you’d restore from the most recent backup. Everything between that backup and now is gone: the invoices entered this morning, the estimate finished an hour ago. Backups taken nightly mean an RPO of up to 24 hours — a full day of work at risk. Hourly protection means one hour at risk.

RTO — recovery time objective — is how long you can afford to be down. The clock from “it’s broken” to “we’re working again”: diagnosing, restoring, verifying. Minutes? Hours? Days? That’s your RTO — and it’s a target you choose, which your backup design then has to actually meet.

Same disaster, two different pains: RPO is the work you redo; RTO is the work you couldn’t do at all. You need a number for each, and they’re business decisions wearing technical clothes — which is why they shouldn’t be set by whoever configures the backup software.

Setting your numbers honestly

The method is one question per number, asked about your busiest realistic day, not your quietest.

For RPO: “If we lost everything since the last backup, what would that cost to recreate — and could we even recreate it?” Some data re-enters from paper in an annoying afternoon. Some — the day’s orders, a signed document, a clinic’s charting — doesn’t reconstruct at all. Where re-entry is impossible or the volume is high, your RPO shrinks toward an hour or less.

For RTO: “What does an hour of downtime cost us — and at what hour count does inconvenience become damage?” Put a real dollar figure on it: idle payroll, stopped orders, missed deadlines, and the clients who quietly conclude you’re flaky. The honest number is usually smaller than the comfortable one — very few businesses that say “we could manage a couple of days” have actually imagined day two.

Then — the step everyone skips — tier your systems. Not everything deserves the same numbers. The order system or ERP might warrant an RPO of one hour and an RTO of four; the marketing archive can be fine at a day and a week. Uniform gold-plating wastes money; uniform economy risks the business. Three tiers is plenty, decided once, on a calm day, in the annual plan.

Why the numbers dictate the purchase

Here’s what makes RTO/RPO practical rather than academic: each combination points at a specific class of solution, which is how you evaluate what a vendor quotes you.

  • RPO of a day, RTO of a few days — nightly cloud backup alone can do this. Cheapest tier; fine for genuinely tolerant businesses and low-tier systems.
  • RTO of hours — restoring a full server from cloud storage alone takes longer than people expect (downloading terabytes is physics, not effort). Hours-not-days means local backup copies for fast restores, layered with offsite per 3-2-1.
  • RTO of minutes-to-an-hour on critical systems — you need backup that can run your server as a temporary virtual machine while the real one is rebuilt: a BCDR appliance or cloud-failover service. Costs more; exists precisely for businesses where the honest downtime number is brutal.
  • RPO of minutes — continuous or near-continuous replication on the specific systems that warrant it.

This is also your defense against both under- and over-selling: a quote should trace to your numbers. “Why does this design meet an RTO of four hours for the order system?” is the whole evaluation in one question.

The fine print that bites

Two things quietly break RTO/RPO promises. Untested restores: your real RPO isn’t your backup frequency — it’s the frequency of backups that actually restore, which is why testing is the half of backup most businesses skip. And declared vs. demonstrated RTO: the clock includes noticing the failure, deciding, and beginning — not just the restore itself. A tabletop run-through of “the server died at 9 a.m., go” is how a paper RTO becomes a real one. Your insurer, incidentally, asks about both.

The bottom line

RPO: how much work you can lose. RTO: how long you can be down. Set both honestly, per tier, from business pain rather than technical convenience — then make your backup spending answer to them. Businesses that can state their two numbers make calm, right-sized recovery decisions. Businesses that can’t are carrying whatever numbers their current setup happens to deliver — and most find out what those are at the worst possible moment. For the hardest grading this region offers those two numbers, see what Cascadia planning asks of them.