Recovery time objective and recovery point objective appear in most enterprise contracts and disaster recovery policies, usually as numbers somebody chose because they sounded responsible. RTO is how long you may take to restore service after a failure. RPO is how much data you may lose, measured in time. Both are commitments, and both have an architecture and a cost attached that is rarely traced back before signing.
RPO is the more expensive of the two and the more commonly misunderstood. An RPO of twenty-four hours means nightly backups are sufficient. An RPO of one hour means continuous or near-continuous replication. An RPO approaching zero means synchronous replication to a second location, which adds latency to every single write your application performs - so the cost is not only infrastructure, it is the performance of the system on an ordinary day. Teams commit to aggressive RPOs without realising they have just made a permanent trade against normal-case latency.
RTO is mostly a test of preparation rather than technology. Restoring a database from backup is not the hard part; the hard part is DNS propagation, certificates that live only on the failed machine, configuration nobody documented, a dependency that points at a hardcoded address, and the twenty minutes spent establishing who has authority to declare a disaster. Organisations with a four-hour RTO on paper routinely discover a real recovery takes a day, because the plan was written and never rehearsed.
Which brings up the only thing that makes either number meaningful: a restore rehearsal. Not verifying that a backup file exists - actually restoring it into a working environment and timing the process end to end, with the people who would really be on duty. Backups that have never been restored should be assumed broken, and the failure modes are mundane: an incomplete dump, a missing encryption key, a retention policy that quietly deleted what you needed, a schema the current application no longer understands.
It is also worth setting these numbers per system rather than globally. The customer-facing transaction path may genuinely warrant an RPO of minutes. The internal reporting warehouse can almost certainly tolerate a day, and paying for continuous replication of it is money spent for no benefit. A single organisation-wide figure is either too expensive for most of the estate or too weak for the part that matters.
Before agreeing to either number in a contract, three questions settle it. What replication does this RPO require, and what does that do to write latency? Has a full restore been rehearsed within this RTO, and when? And who is authorised to declare a disaster at two in the morning, because the clock on your RTO starts at failure and not at the moment someone senior finally answers the phone.
