HA versus backup versus DR; RPO and RTO with real arithmetic · PostgreSQL

Three different problems, frequently conflated, and each one leaves the others uncovered.

What each addresses

	Covers	Does not cover
High availability	A host or process failing	Anything that replicates
Backup	Data destroyed or corrupted	Being unavailable meanwhile
Disaster recovery	A site, region or provider lost	Either of the above on its own

The dividing line between HA and backup is sharp and worth stating plainly:

HA protects against a machine stopping. Backup protects against data becoming wrong.

A DROP TABLE replicates to every standby in milliseconds. So does a migration that updated every row with a bad WHERE clause, an application bug writing nonsense, and a DELETE without a predicate. Every one of those is faithfully copied to every replica, because faithful copying is exactly what replication is.

RPO and RTO, computed

Both are two numbers, and only the measured ones mean anything.

Recovery point objective

Asynchronous replication. Whatever had not reached the standby. Measured in lesson XIV-04: 2.5 ms at 1,623 tps on a healthy pair — and lesson XIV-07 measured the same pair 30 seconds and 124 MB behind when one query conflicted with replay. Your RPO is the second number, not the first, because failures do not wait for the system to be healthy.

Synchronous replication. Zero, for anything acknowledged. Lesson XIV-05 measured the cost at 9% throughput on a loopback pair, dominated by the network round trip in any real deployment.

Backup plus archive. Bounded by archive_timeout and archive lag. With archive_timeout = 60, up to 60 seconds — plus however long the archive is behind, which lesson XIII-05’s pg_stat_archiver query is for.

Backup alone. The interval between backups. Nightly dumps mean a 24-hour RPO, and no amount of care changes that.

Recovery time objective

Add the terms, and be honest about each:

Term	Automated failover	Manual failover	Restore from backup
Detection	`ttl`, ~30 s	Minutes to hours	Same
Decision	Seconds	Minutes	Minutes
Fencing	Seconds	Minutes	n/a
Promotion / restore	89 ms (measured)	89 ms	Hours for a large cluster
Rerouting	Seconds to minutes	Minutes	Minutes
Client reconnection	Seconds to minutes	Same	Same

The database’s own contribution is 89 milliseconds in two of those three columns. Everything else is detection, humans, routing and clients.

Write down the measured numbers, not the intended ones

	Intended	Measured	Measured when
RPO, host failure
RTO, host failure
RPO, data destruction
RTO, data destruction
RTO, site loss

The right-hand columns come from lesson XV-07’s rehearsal and lesson XIII-08’s restore test. If they are empty, the left-hand column is an aspiration.

The fourth column matters as much as the third: a number measured eighteen months and three architecture changes ago is not evidence about today.

What a complete design covers

Work down the list and mark what your current design actually handles:

A PostgreSQL process crashing → restart; Part XII’s crash recovery
A host failing → HA, Part XV
A disk failing → RAID, or HA
A table being dropped → backup and PITR, Part XIII
Data corrupted by the application → backup and PITR
Silent corruption discovered late → backups with enough history
A rack, AZ or region lost → DR: replication and backups elsewhere
A cloud account compromised or deleted → backups outside that account
Ransomware → immutable or offline backups
A person deleting the backups → backups they cannot delete

The bolded items are not covered by any amount of replication. The last three are not covered by backups either, unless the backups are somewhere the same credentials cannot reach — which is the practical meaning of the “3-2-1” convention, and the reason the last line exists.

Why DR is harder than a distant standby, and the number that decides it

The obvious DR design is a standby in another region. It is a good start and it is not disaster recovery on its own, for four reasons.

It replicates mistakes. Same as any standby. A regional replica of a dropped table is a dropped table in two regions.

Cross-region lag is real and variable. A 50 ms round trip means asynchronous replication is at least 50 ms behind, and under load or during a network event, much more. Your cross-region RPO is not your local RPO.

Synchronous across regions is usually unaffordable. Every commit pays the round trip. On a workload committing every 5 ms, a 50 ms round trip is an order of magnitude, not a percentage. Lesson XIV-05’s 9% figure was loopback and does not transfer.

Promotion in another region is a much bigger decision. Everything else — application servers, caches, queues, object storage — is still in the failed region. Promoting the database is the easy part of a regional failover and rarely the part that takes the time.

What a real DR plan needs beyond a replica:

Backups in a different failure domain, ideally a different provider or account, so a compromise or deletion in one does not reach them.
A rehearsed restore into the DR region, since a restore that has only ever run at home is a hypothesis about the DR region.
The rest of the stack, or an honest statement that the database will be available and the application will not.
A decision procedure, because regional failover is rarely reversible and is almost never the right first response to a partial outage.

The number that decides most of this is the cost of an hour of downtime. Below some threshold, “restore from backup into a new region, in a few hours” is the correct DR plan and everything else is over-engineering. Above it, a warm region with rehearsed cutover earns its cost.

Knowing which side of that threshold you are on is a business question, not a database one, and it is the one worth asking before designing anything.

What to take from this

HA covers a machine stopping. Backup covers data becoming wrong. DR covers losing a site. None substitutes for another.
A DROP TABLE replicates in milliseconds. Replicas do not protect against it.
Measured RPO: 2.5 ms healthy, 30 s when replay was blocked. Plan for the second.
Measured promotion: 89 ms. The RTO is detection, humans, routing and clients.
Write down intended and measured numbers, with the date measured.
Backups must be somewhere the credentials that run production cannot delete them.
A distant standby is not DR. Backups elsewhere, a rehearsed restore there, and a decision procedure are.

Cross-course references

Linux for Production Sysadmins — Part L (Disaster recovery) covers RPO and RTO as commitments with arithmetic behind them, and Part LII (High availability fundamentals) covers why availability and recoverability are separate budgets.
Ceph & Distributed Storage — Part CIX (Disaster recovery) and Part CXIX (Disaster recovery architecture) cover the storage layer’s version of the same three-way distinction.
Observability for Production Sysadmins — Part XCII (Disaster recovery) covers monitoring that survives the disaster it reports.