RPO and RTO for people who just have a cron job

RPO and RTO show up in vendor decks and compliance questionnaires, wrapped in enough language to make them sound like something you buy rather than something you measure.

They are two numbers. You already have both. You probably have not written them down, and the second one is almost certainly wrong.

The two numbers

RPO, recovery point objective: how much data you are willing to lose. It is a window of time, measured backwards from the incident. Your RPO is set entirely by how often your backups run.

RTO, recovery time objective: how long you are willing to be down. Measured forward from the moment someone decides to restore. Your RTO is set by how long the restore actually takes, plus everything that happens before anyone starts it.

Working out your real RPO in one minute

If your cron runs at 03:00 daily, your RPO is 24 hours. An incident at 02:55 loses almost a full day of writes.

That is the arithmetic everyone does. It is also optimistic, because it assumes last night's run succeeded. Your effective RPO is the age of your most recent restorable backup, which is a different number:

The gap between the two columns is the whole reason run records exist. Without a record of what each run produced, you know your schedule, which is a statement of intent, and not your RPO, which is a fact.

Your RTO is a guess until you have timed it

Nearly every RTO figure quoted internally is the time the restore command takes, measured once, on a good day, by the person who wrote it.

The real clock starts earlier and runs longer:

1. Detection. Someone notices. On a bad day this is hours.
2. Decision. Someone decides restoring is correct, which usually needs a second person who is asleep.
3. Locating. Which artifact, from when, in which bucket, under which key.
4. Retrieval. Download time, which people forget scales with size and their own bandwidth. 200 GB is not instant.
5. Restore. The number everybody quotes.
6. Verification. Confirming it worked before you point traffic at it.
7. Reconciliation. Replaying whatever happened during steps 1 through 6.

Steps 1, 2 and 7 are usually larger than step 5, and none of them appear in a vendor's RTO claim, because none of them are the vendor's.

How to actually measure both

An afternoon, once:

For RPO, look at your most recent verified backup, not your most recent backup attempt. If you cannot tell the difference from your tooling, that is the finding. Age of that artifact is your effective RPO.

For RTO, run the restore. Start a timer when you decide to, not when you type the command. Restore into a scratch environment, verify row counts, and stop the timer when you would have been comfortable sending traffic to it. Whatever number comes out is your RTO, and it will be larger than what is written down.

What we do with these two numbers

We do not set your RPO. Your schedule does, and that is your call.

What we do is make the effective number match the stated one, which is where these usually diverge. Every run leaves a record: what ran, what it produced, how large it was against previous runs, where each copy went, and what failed. A missing or anomalous run is visible rather than silent, so the age of your last good artifact is a thing you can read rather than a thing you assume.

For RTO, our contribution is smaller and more specific. The restore path is documented, uses standard tools, and does not require us to be reachable, which removes one of the steps above from your critical path entirely.

The summary

Your RPO is your schedule, corrected for the runs that failed. Your RTO is a guess until you time a real restore, and it is longer than you think, mostly because of the parts that have nothing to do with technology.

Write both down. They are the two numbers that determine what a bad day costs you, and neither of them needs a procurement process to find out.