Set RPO and RTO Targets Before You Design DR

Before you design any disaster recovery, answer two questions with numbers. How much data can you afford to lose, measured in time? That is your RPO, the recovery point objective. How long can you afford to be down before service comes back? That is your RTO, the recovery time objective. Every backup schedule, every replication decision, every dollar you spend on redundancy flows from those two numbers. Pick them first and the design becomes obvious. Skip them and you will either over-build and waste money or under-build and lose the company.

What RPO and RTO actually mean

RPO is about data loss. If you take a backup every 24 hours and the server dies right before the next one, you lose up to 24 hours of data. Your RPO is 24 hours. If losing a full day of transactions would sink you, that number is wrong and you need more frequent capture.

RTO is about downtime. If rebuilding a dead server, restoring the database, and pointing DNS takes you four hours, your RTO is four hours. If your customers walk after one hour of downtime, four hours is a business failure, not a technical detail.

The trap is that people conflate the two. A fast restore does not help if the backup is a day old. A fresh backup does not help if it takes you six hours to stand the app back up. You need both numbers, and you need them to be true, not aspirational.

How to pick the numbers for a real business

Do not pull them from a template. Derive them from what the data is worth.

• Ask what an hour of lost data costs. For a payments app, it is enormous. For a marketing site, it is close to zero.
• Ask what an hour of downtime costs. Lost sales, broken SLAs, support load, reputation.
• Set RPO and RTO where the cost of tighter targets stops being worth the spend.

For most of my portfolio, the honest answer is generous. A content site can tolerate a 24-hour RPO and a two-hour RTO, so I do not spend a dime on hot standby for it. But the shared Postgres box under the revenue apps gets a tight RPO measured in minutes, because losing an afternoon of customer data there would hurt real people. Different data, different targets, different spend. That is the whole point of setting them per system instead of buying one plan for everything.

The numbers dictate the design, not the other way around

Once you have RPO and RTO, the architecture stops being a debate.

A 24-hour RPO means a nightly dump is enough. A one-hour RPO means hourly snapshots. A near-zero RPO means continuous capture, which for a database means shipping the write-ahead log and doing point-in-time recovery rather than relying on dumps at all. The tighter the RPO, the more continuous your capture has to be. There is no way around that math.

RTO works the same way. A two-hour RTO means a scripted rebuild is fine: provision a box, restore, cut over, done. A ten-minute RTO means the rebuild is too slow and you need a warm standby already running and replicating, ready to promote. Warm standby costs real money because you pay for a second box that mostly sits idle. You only pay that if the RTO demands it. Most systems do not.

Write the numbers down and test against them

An RPO and RTO you never verify are fiction. The only way to know your real RTO is to run restore drills and time them. Almost every first drill blows past the target, and that gap is the most useful thing you will learn all quarter. Either you tighten the process until you hit the number, or you admit the real number and stop lying to yourself and your customers.

I keep the targets written next to each app so the recovery plan is not stored in my head. When a box dies, I am not improvising. I know the RPO I promised and the RTO I have to hit, and the runbook already reflects both. That discipline is what turns disaster recovery when you self-host from a scary unknown into a routine you have rehearsed.

I run the whole portfolio on plain VPS boxes through HostSSH, and the reason self-hosting does not scare me is that I set the numbers first. RPO and RTO are not enterprise paperwork. They are the two decisions that make every other decision easy. Set them before you spend anything.