High availability ≠ continuity ≠ recovery

Three arrangements, three threats

The right-hand column is what matters. Each arrangement has a blind spot, and the previous one's blind spot is the next one's reason to exist.

The scenario that crosses all three

Take a logical corruption: a faulty application write, propagated into the production database at 14:00.

• High availability sees nothing: the nodes are healthy, the service responds.
• Replication to the remote site faithfully carries the corruption. At 14:00:01, both sites are corrupted.
• Only the backup allows a return to 13:00. It is slow, it loses an hour of data, and it is the only option.

That is why an architecture investing everything in availability and neglecting backup is structurally fragile: it is excellent against hardware failure, which has become rare, and defenceless against corruption and ransomware, which have become frequent.

Deriving technical objectives

The technical RTO is never equal to the business RTO: it must leave room.

Business RTO = detection + decision + technical RTO + verification + operational resumption

A 4-hour business RTO, with 30 minutes of detection, 45 minutes of decision, 45 minutes of verification and 30 minutes of operational resumption, leaves 1 h 30 of technical RTO.

Many architectures are sized for 4 hours when they actually have an hour and a half. The gap only appears at the first measured exercise.

The application RPO is not the storage RPO

Storage replicated every fifteen minutes does not guarantee a fifteen-minute RPO for the application. Three factors add on:

• In-flight transactions at the moment of the cut, which can leave inconsistent states;
• Flows between applications: application A is current, application B is fifteen minutes behind, reference data diverges;
• Files deposited by third parties, which do not follow the database replication cycle.

The real RPO is measured by restored functional consistency, not by the timestamp of the last replicated block.