Derive the RPO your replication mode and backup interval actually deliver, the data at risk in the worst case, and the interval a target demands.
The detection term is what most RPO calculations omit: your copy is only as good as the last point before the damage, so the minutes before anyone notices count against the objective just as much as the replication interval. That single term is why continuous replication does not automatically give a near-zero RPO against logical corruption, which propagates faithfully to the replica. RPO is where policy and physics diverge most often — nightly backups and a one-hour RPO appear together in real documents. This is an estimate from your own intervals and change rate; only a verified restore proves the recovery point.
Disaster Recovery RPO
Achievable RPO = replication lag or interval + time to notice. Synchronous gives 0, asynchronous gives lag + detection, log shipping gives the shipping interval + detection, and backup-only gives the full backup interval + detection.
Data at risk
Data at risk = change rate × achievable RPO; the interval a target demands = target RPO − detection time.
Achievable RPO = replication lag or interval + time to notice. Synchronous gives 0, asynchronous gives lag + detection, log shipping gives the shipping interval + detection, and backup-only gives the full backup interval + detection. The detection term is what most RPO calculations omit: your copy is only as good as the last point before the damage, so the minutes before anyone notices count against the objective just as much as the replication interval. That single term is why continuous replication does not automatically give a near-zero RPO against logical corruption, which propagates faithfully to the replica.
RPO is where policy and physics diverge most often — nightly backups and a one-hour RPO appear together in real documents. This is an estimate from your own intervals and change rate; only a verified restore proves the recovery point.
This calculator takes 8 inputs: Data protection mode, Backup interval, Typical asynchronous replication lag at peak, Log shipping interval, Data change rate, Time to notice the loss and stop writing, Target RPO, Restores verified from these copies in the last quarter. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Against infrastructure failure, effectively yes. Against ransomware or a bad deployment, no — the replica receives the corruption as faithfully as the good data, so the useful recovery point is your last clean copy. That is why an immutable, independent backup remains necessary alongside replication.
Peak, or better the p99. Lag matters precisely when write volume is highest, which is often when incidents happen, and a system averaging two seconds of lag can sit minutes behind during a batch window. Sizing on the average is the most common way an RPO is quietly missed.