RPO and RTO: the two numbers your backup scheme grows from

"We back up once a day" is an answer with no question behind it. The real question is different: how much data is the business willing to lose, and how long is it willing to stay down. The answers are called RPO and RTO, and everything else follows from those two numbers.

RPO: how deep the loss goes

RPO (Recovery Point Objective): how much data you can afford to lose, measured in time.

RPO is a requirement, not a report. The business states the acceptable loss first, then the schedule gets built around it. A nightly dump at 3 a.m. satisfies an RPO of 24 hours, and no better: an outage at 2 p.m. takes everything that happened since 3 a.m. with it. Need an RPO of one hour? Back up once an hour.

Count it in money and commitments, not files. A lost day of orders for an online shop is a specific amount of money and specific calls to customers. A lost day of build logs costs almost nothing.

So RPO is different for different data in the same project, and that's normal: the orders database once an hour, an analytics data mart once a day, a cache with no backup at all.

The actual loss is simple to calculate. Take the time of the last record that made it into the latest copy, and the time of the outage. Everything between them is gone. If that gap is longer than the RPO, the requirement wasn't met.

RTO: how long the downtime lasts

RTO (Recovery Time Objective): how fast the service has to come back.

An RTO of four hours means everything has to fit inside those four hours: noticing the outage, deciding to restore, finding the right copy, deploying it, verifying it, and switching traffic over.

That's why teams usually miss their RTO for reasons that have nothing to do with disk speed. An hour goes into figuring out what even happened, another hour into finding someone with access, and only then does the actual restore begin.

Work it out for your own service: how long would it take to download 200 GB from object storage over your connection? To deploy a database dump that size? To rebuild the server configuration? Add that to detection and finding people, and you get an honest RTO. Restoring a small database from a dump takes seconds, and that's easy to check by hand (the second lab in this lesson).

How the numbers turn into a scheme

RPO dictates the frequency and the method:

• a day: a nightly dump is enough;
• hours: more frequent dumps plus snapshots;
• minutes: continuous archiving of the transaction log (in PostgreSQL, that's WAL). The archive_timeout parameter makes the server push the log to the archive at least as often as the set interval; the docs consider about a minute a reasonable value;
• seconds: asynchronous streaming replication, where the replica usually lags by less than a second;
• zero for committed transactions: synchronous replication. The commit waits until the write lands on disk on both the primary and the replica. Data is lost only if both servers go down at the same time.

RTO dictates how you store the copies:

• a hard RTO: keep the latest copy close by and ready to deploy, or the download alone will eat the whole deadline;
• a soft RTO: archives can move to cold storage, where keeping them is cheaper but retrieval takes hours. For example, Amazon S3 Glacier Flexible Retrieval takes 3–5 hours for a standard retrieval, and Glacier Deep Archive up to 12 hours.

That's where the typical layered setup comes from: a hot copy for today kept close by, weekly archives in object storage, monthly ones in a cold tier.

Who sets the numbers

Not the engineer. RPO and RTO are business decisions, because money sits behind both of them: the cost of downtime, and the cost of the infrastructure that shortens it.

The engineer translates the wish into a price. "We want zero RPO and a five-minute RTO" isn't backups anymore, it's a hot standby in another region with continuous replication, and it costs many times more than a nightly dump. Once the numbers get compared with the price, the requirements usually get more realistic.

Write the agreed values down. In the middle of an outage, "I think we agreed on four hours" doesn't work well.

Common mistakes

• Counting RPO by the schedule instead of the worst case. A daily backup means a loss of up to 24 hours, not "a little on average".
• Restoring from the wrong file. Before deploying, check which copy is the newest and that it really holds the latest data.
• Measuring RTO only by the time pg_restore or a download takes. Detection, finding access, verification, and the traffic switchover all count toward the deadline too.
• Running a "trial" restore straight into the production database. Drills belong in a separate database or on a separate server.
• One RPO for all data. A cache and an orders database need different ones.

What you'll need for the tasks

• docker exec <container> <command> to work with postgres inside the container;
• createdb, dropdb, and psql -d <database> -c "<SQL>";
• loading a SQL dump: psql -d <database> < file.sql (wrapped in sh -c inside the container);
• a custom-format dump (pg_dump -Fc) can only be read by pg_restore -d <database>;
• SELECT count(*), SELECT max(...), and WHERE ... > '<time>';
• time <command>, the real line in the output.

Next up is the 3-2-1 rule: exactly where copies need to live so one outage can't kill all of them at once.