← Back to Concept Contrast

Concept Contrast Fable

Recovery Time Objective and Recovery Point Objective

Conclusion first:RTO asks "how long after a failure until normal operation is restored," while RPO asks "how much time's worth of data loss is allowed." RTO determines how many machines you need to prepare and whether you need hot standby; RPO determines how often you back up, and whether incremental backup is enough or real-time sync is required. When a client presents both goals to you as the same "recovery requirement," your architecture cost could differ fivefold.

RTO asks "how long after a failure until normal operation is restored," while RPO asks "how much time's worth of data loss is allowed." RTO determines how many machines you need to prepare and whether you need hot standby; RPO determines how often you back up, and whether incremental backup is enough or real-time sync is required. When a client presents both goals to you as the same "recovery requirement," your architecture cost could differ fivefold.

Fable

Fire brigade and archive

The money house feared the accounting office would catch fire, and the shopkeeper asked two things. The head of the accounting office managed two seemingly similar matters: one was how soon they could reopen for deposits and payments, and the other was how far back in the accounts they could afford to lose. The new clerk found it troublesome and merged the two ledgers into one, thinking it was all related to success or failure anyway.

At first no one objected. The clerk merged the two questions into "backups should be good," bought an iron box, and felt at ease. The shopkeeper saw fewer pages and even praised them for saving trouble. But when peak season arrived, the old accounts suddenly could not be explained clearly: whether the previous batch had not been finished or the next batch had not been held, no one could answer.

They first added more seals and slogans and required everyone to write in more detail. As a result, the booklet grew thicker and disputes increased. When something went wrong, everyone could find a sentence to excuse themselves, but no one knew which end to save first.

The old steward called everyone into the courtyard and had them retrace the actual course of events. Whatever concerned the immediate action went into the first book; whatever concerned subsequent responsibility went into the second. The two books referenced each other, but were no longer mixed onto the same page.

After the fire, the iron box preserved the accounts from three days earlier, but the counter could not be rebuilt in half a day, and yesterday's transactions could not be recovered. Once separated, many old conclusions changed: some activities looked busy but had not actually blocked trouble; some arrangements were unremarkable in normal times yet preserved the whole in disaster.

To prevent newcomers from mixing things up again, the old steward had them each handle a small case. Only when the two ledgers could each answer their own questions and also connect with each other at the boundary would the small case pass. If someone still wrote the two matters on one page, they had to return to the scene and look again at who acted first and who was ultimately responsible; when it was unclear, it was better to ask once more than let a muddled account stay overnight; because on the day something truly went wrong, one missing line of distinction would make an extra team work in vain.

The shopkeeper set separate rules: the counter had to be able to open temporarily within one incense stick's time, and the ledger had to be copied next door every half shichen. Later, when newcomers entered the trade, the old steward had them memorize just one line: recovering quickly and losing fewer old accounts are two different rulers.

Recovery time objective

The maximum acceptable time for a system or service to recover from an interrupted state to normal operation. It defines "how long you can wait" and determines whether disaster recovery architecture chooses cold standby, warm standby, or hot standby.

Recovery point objective

The maximum data loss window a system can accept after a failure, usually measured in time. It defines "how much can be lost" and determines backup frequency—hourly backups, real-time synchronization or daily backups.

Story Mapping

  • The time for the fire brigade to reach the scene: RTO—measuring fault response speed.
  • Interval covered by archive backups: RPO—measures the upper limit of data loss.
  • Four-hour recovery but two hours of data lost: RTO is met but RPO was never defined, greatly undermining disaster recovery effectiveness.
  • Hot standby servers cut RTO to one hour: the technical investment needed to shorten recovery time.
  • Switch to near-real-time sync to push RPO down to five minutes: the technical investment needed to shorten the data loss window.

In the project

When receiving disaster recovery requirements, break RTO and RPO into two independent parameters and ask the customer. Different modules in the same system can have different RTO/RPO—the payment module's RPO may require zero loss, while the reporting module's RPO can accept one day. Only after separating them can architects design differentiated solutions, avoiding covering all modules with one strictest number and causing overall costs to spiral.

京ICP备2026014272号