Two questions, two units. The recovery point objective is bytes: the backup interval multiplied by the write rate, 1.73 TB at a daily backup and 20 MB/s of writes. The recovery time objective is hours: the dataset over the restore bandwidth plus the log replay, 12.38 h for two terabytes. Shortening the interval moves both — and cannot touch the copy, which is the floor under either promise.
Core ideas
The whole lesson is that these are different numbers. Everything else is two multiplications and a division.
The recovery point objective asks how much work is lost: the backup interval times the write rate, in bytes. The recovery time objective asks how long the system is down: the dataset over the restore bandwidth, plus replaying whatever log survived. They answer different questions, they are measured in different units, and a single statement cannot satisfy both.
The worst case is a failure one instant before the next backup, losing a whole interval of writes: 1.73 TB at a daily backup and 20 MB/s. A failure at a uniformly random moment inside the interval loses half of that on average, 864.00 GB. Quote both — the first is what you must survive and the second is what you will typically pay.
Halving the backup interval halves the bytes at risk and halves the replay, but copying 2.00 TB back at 200 MB/s takes 2.78 h on every row of the table. No backup schedule in existence makes a restore faster than the time it takes to move the data, which is why an aggressive RTO target is a statement about bandwidth and dataset size rather than about backups.
The material
Two formulas, the difference between worst case and expected, and what a target actually constrains.
The recovery point objective (RPO) is the volume of writes lost by a failure, measured in bytes: at most interval × write rate, and interval × write rate / 2 in expectation for a failure at a uniformly random moment.
The recovery time objective (RTO) is the elapsed time to be serving again, measured in hours: size / restore bandwidth + surviving log / replay rate.
Writing them side by side is most of the work, because the two are routinely collapsed into one sentence about backups existing. They are controlled by different things: the RPO by the schedule, the RTO by bandwidth. Doubling the backup frequency improves the first proportionally and the second hardly at all.
Notice what dominates. Of the 12.38 h, the copy is 2.78 and the replay is 9.60 — so on this schedule most of the outage is spent reapplying a day's worth of log, and the fastest available lever is the backup interval rather than the restore path. That balance flips as the interval shortens, which is exactly why both terms have to be computed rather than one of them assumed dominant.
It buys twice: fewer bytes at risk, and less log to replay. Backing up hourly instead of daily takes the RPO from 1.73 TB to 72.00 GB and the RTO from 12.38 h to 3.18 h — a factor of twenty-four on the first and most of the way to the floor on the second. What it does not touch is the 2.78 h of copying, which sits under every row.
At 20 MB/s of writes into a 2.00 TB dataset restored at 200 MB/s with 50 MB/s of replay: one hour gives 72.00 GB at risk and an RTO of 3.18 h; six hours, 432.00 GB and 5.18 h; twelve hours, 864.00 GB and 7.58 h; twenty-four hours, 1.73 TB and 12.38 h. The RPO is linear in the interval and so is the replay, so the RTO is a straight line starting at 2.78 h.
Run it backwards to turn a target into a schedule. A four-hour RTO leaves 4 h − 2.78 h = 1.22 h for replay, which at 50 MB/s is about 220 GB of log, which at 20 MB/s of writes is 3.06 h of interval. So “we must be back inside four hours” is, on this hardware, a requirement to back up at least every three hours — and if the copy alone exceeded four hours the target would be unreachable at any schedule, which the arithmetic says immediately.
The misconception this page exists for is offering “we have backups” as an answer. It is not a number of bytes, so it is not an RPO; it is not a number of hours, so it is not an RTO. Both of the real answers are one multiplication away from figures an operator already has, and the unwillingness to produce them is usually a sign that nobody has timed a restore.
Which is the honest caveat. Restore bandwidth must be measured on a real restore, not assumed from a network specification; a backup that has never been restored is a forecast rather than a fact. And this model starts the clock at the moment of failure, while a real outage also contains detection and the decision to restore — neither of which is in these two formulas and both of which are in the outage.
Interactive
Bytes at risk from the schedule, hours to restore from the bandwidth
Method
Two multiplications, one addition, and then the same arithmetic run backwards.
That is the worst-case RPO in bytes: 86 400 s × 20 MB/s = 1.73 TB for a daily backup. Use the write rate, not the read rate and not the ingest of the busiest hour unless that is the hour you are protecting.
A failure at a uniformly random moment inside the interval loses half the worst case on average, 864.00 GB here. The worst case is what a commitment has to survive; the expected case is what the business will actually experience.
size / restore bandwidth plus RPO / replay rate. Write the two terms separately: the first is the floor and cannot be moved by the schedule, and seeing which of the two dominates tells you which lever is worth pulling.
Subtract the copy from the target, multiply what is left by the replay rate to get a log size, and divide by the write rate. A four-hour target on this hardware allows 3.06 h between backups. If the copy alone exceeds the target, no schedule reaches it and the conversation is about bandwidth.
The two objectives, then the same arithmetic at four intervals, then run backwards from a target.
The copy column never moves. 2.78 h is the floor under every recovery promise this hardware can make, and only a faster restore path or a smaller dataset lowers it — no backup schedule does. That is the single most useful sentence on this page, because it converts an argument about backup frequency into an arithmetic fact about bandwidth.
Shortening the interval buys on both axes at once, which is unusual enough to be worth saying out loud: from twenty-four hours to one, the bytes at risk fall by a factor of twenty-four and the recovery time falls from 12.38 h to 3.18 h, which is within half an hour of the floor. Past that point more frequent backups buy almost nothing.
For a faded rehearsal, keep the daily schedule and double the restore bandwidth to 400 MB/s. The supplied first move is that the copy falls to 1.39 h. Compute the new RTO, then say what a four-hour target now allows as a backup interval, and why that answer moved so much further than the RTO did. Check both in the lab before opening the quiz.
You should be able to compute worst-case and expected RPO from a schedule and a write rate, compute RTO from a dataset, a restore bandwidth and a replay rate, and invert the second to say what backup interval a stated target allows.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.