Backup and point-in-time recovery

What sets RPO and what sets restore time, and what makes a backup independent?

Snapshots do not cover this, and without it rung 6 of the ladder is unbought.

The important operational view:

• Backup frequency controls restore time, not RPO. A base further back means more log to replay.
• Log shipping lag controls RPO. If you archive the WAL every 60 seconds, your RPO is 60 seconds, whether you take full backups every hour or every week.

People often tune the wrong one and are surprised by their data-loss window.

This is the same equation as checkpointing, evaluated in days instead of seconds. So base + log is the most reused mechanism in the whole subject:

Eight forms, one mechanism.

What backups need that snapshots do not: independence

The protection does not come from the extra copy. It comes from two kinds of decoupling:

1. In time. The backup is old enough that the damage has not reached it.
2. In authority. The backup is held under credentials that the damaging path does not have.

Independence is an assumption, not a property. A backup in the same cloud account, reachable with the same credentials, and deleted by the same automation is not independent of the failures that actually destroy companies. Object-lock (immutable retention: the storage refuses deletes until a date) is the escape, and it costs you the ability to delete, which collides with erasure obligations (see Log truncation and retention policies).

And one more item that is in almost nobody's plan: an unverified backup is a hypothesis, not a backup. Restore testing is the only mechanism in this whole mechanism that actually samples the rare path. It is the activity with the highest information gained per dollar. A backup that silently fails to capture the data shows the same green dashboard as one that works, for years: backups are write-only until tested. The test is a periodic restore into a scratch environment, followed by a row-count and checksum comparison.

Restore bandwidth is the real constraint

Backup is continuous, throttled, incremental and off the critical path. Restore is a single urgent bulk transfer, plus log replay, plus index rebuild, plus cache warming. Backup bandwidth tells you nothing about restore bandwidth.

Recovery by recomputation: a different answer

Not every system recovers by replaying a durable output log. Spark's strategy is: do not make the writes survive; make the inputs and the function survive. It is a genuinely different answer to "how do writes survive?", a peer of the WAL, explained in Checkpoints and lineage: save the state or the recipe.

How snapshots and backups sit on three trade-offs