Work back from the RTO and RPO you set
The RPO is how much data, measured in time, you can afford to lose in an incident; the RTO is how long the service may stay down. Enter both targets plus data size and change rate, and this page computes the maximum backup or replication interval, the replication mode required, and the restore throughput needed to meet the RTO. Add your measured throughput and it also compares whether the current setup can hit the targets.
The maths is a plain inversion. The backup interval cannot exceed the RPO, and an RPO of 0 leaves no interval at all, so synchronous replication is required. Time left for restoring is the RTO minus detection and switchover, and the required throughput is the data size divided by that time. Sizes convert at 1 GB = 1,024 MB and the formula used is printed with the result. Current as of October 2026.
The RTO and RPO targets themselves come out of a business impact analysis and have no official recommended values, so this page suggests none. The model assumes one sequential restore, so parallel restores, replaying logs after an incremental recovery and consistency checks are not included. Deriving the number of recovery points and retention storage from a backup schedule belongs to a separate tool.
Frequently Asked Questions
No. Targets come out of a business impact analysis and have no official recommended values. This page suggests none and instead works back from the targets you set to the backup interval and restore throughput they require.
No interval is allowed, so synchronous replication is required. A commit is acknowledged only after it reaches the remote site, so write latency grows by the round trip and cost rises as well.
Yes. Noticing the outage, deciding to switch over and letting that switch propagate all consume the RTO, and only the remainder is available for the restore, which is why both are separate inputs here.