Exercise 3: Why the RPO Assumption Held Up and the RTO Assumption Didn't — Possible Solution ==================================================================== WHAT THE STAKEHOLDERS ACTUALLY ASSUMED ------------------------------ Per this chapter, the shared belief was "we back up every night, so we can never lose more than a few hours" - one sentence, quietly bundling together an assumption about data loss and an assumption about recovery speed, as though nightly backups automatically implied both. WHY THE RPO PART OF THE ASSUMPTION WAS REASONABLE ------------------------------ RPO, per this chapter, is "directly tied to how often backups run." Nightly backups genuinely do mean that, at worst, everything since the last nightly run could be lost - up to roughly 24 hours, which is "reasonably close" to the stakeholders' own "a few hours" framing (off in degree, but built on the right underlying mechanism). Backup frequency actually is the thing that determines RPO, so reasoning from frequency to a data-loss estimate was reasoning from the correct variable, even if the specific number quoted was optimistic. WHY THE RTO PART OF THE ASSUMPTION WAS BUILT ON THE WRONG VARIABLE ENTIRELY ------------------------------ RTO, per this chapter, is "directly tied to how long an actual restore takes" - a completely different mechanism from backup frequency. Nightly backups say nothing about how long a restore of that data would take once started; a backup could run nightly for years while the actual restore process itself remains slow, complex, or untested. The stakeholders' assumption "we back up every night" was simply irrelevant to the RTO question, which is why using it to estimate RTO produced a wildly wrong answer (a few hours assumed vs. 18 hours actual) rather than a merely imprecise one. WHY THIS IS A DIRECT CONSEQUENCE OF RPO AND RTO BEING GENUINELY DIFFERENT QUESTIONS ------------------------------ Since backup frequency is the correct input for RPO but has no bearing on RTO, any single assumption built from frequency alone will naturally track RPO reasonably well while telling you nothing reliable about RTO - exactly the pattern this worked example demonstrates. WHY THIS WORKS AS AN ANSWER ------------------------------ It restates the stakeholders' single combined assumption, explains why backup frequency is the correct driver of RPO specifically (making that half roughly right), and explains why frequency has no bearing on RTO at all (making that half badly wrong for a structural reason, not just bad luck).