RPO and RTO calculator: can your backups meet your targets?

Enter your recovery targets, how often you back up and how much data you would have to restore. You see the worst-case data loss and recovery time against each target, with the sums shown.

How to read the result

• Worst-case data loss is the most data, measured in time, you could lose if the failure came at the worst moment: just before the next backup was ready to restore. Compare it with your RPO.
• Estimated recovery time adds up the steps from noticing the problem to the service running again, with the restore itself worked out from your data size and restore speed. Compare it with your RTO.
• Longest backup gap that meets the RPO tells you how often you need to back up.
• Restore speed needed for the RTO is the speed your restore has to reach once the other steps have taken their share of the RTO.

How are RPO and RTO calculated?

RPO and RTO are targets that the organisation sets. AWS defines RPO as the maximum acceptable amount of time since the last data recovery point, and RTO as the maximum acceptable delay between the interruption of service and restoration of service. This calculator works out what your setup actually delivers and compares it with those targets.

1. Worst-case data loss. backup interval + job run time + offsite copy lag. A backup only counts once its job has finished, and the offsite copy only once it has caught up, so the worst moment for a failure is just before the next one is ready. The lag only applies when you restore from the offsite or immutable copy.
2. Restore time. TB x 1,000,000 MB / restore speed in MB/s / 3,600 gives hours, using decimal units (1 TB = 1,000,000 MB).
3. Recovery time. notice and decide + get somewhere to restore to + restore time + check and bring back.
4. Restore speed needed. TB x 1,000,000 / ((RTO - the other steps) x 3,600). If the other steps alone take longer than the RTO, no restore speed will meet it.
5. MTD. If you enter a maximum tolerable downtime, the calculator flags an RTO or a recovery time longer than it. In our view the RTO of every system a process depends on should be shorter than that process's MTD.

Worked example: nightly backups and 2 TB to restore

A business sets a 24-hour RPO and a 12-hour RTO for a file server. The backup runs nightly and takes an hour, and the server holds 2 TB, restored over 1 Gb Ethernet at its 125 MB/s line rate. It allows an hour to notice the problem and decide, two hours to get a server ready and an hour to check the data. These are the calculator's defaults.

• Worst-case data loss: 24 + 1 = 25 hours, which misses the 24-hour RPO by an hour. Backing up every 23 hours or less would meet it.
• Restore: 2 x 1,000,000 / 125 / 3,600 = 4.4 hours.
• Recovery time: 1 + 2 + 4.4 + 1 = 8.4 hours, inside the 12-hour RTO.
• Restore speed needed: the other steps take 4 hours, which leaves 8 hours for the restore: 2 x 1,000,000 / (8 x 3,600) = about 70 MB/s.

Restoring from the offsite copy after ransomware, with a two-hour copy lag, raises the worst-case loss to 27 hours.

What are the calculator's limitations?

• Restore speed is not steady. Many small files, deduplicated or cloud storage and a busy network all slow a restore down. A timed restore test gives the real figure, and our guide to how often to test disaster recovery plans covers testing.
• One system at a time. When several systems restore at once they share the same network and storage, and some cannot start until the ones they depend on are back.
• Ransomware takes longer. Finding a clean restore point, rebuilding servers and checking for the attacker can add days that a simple restore does not show. Put that time in "get somewhere to restore to".
• Snapshots and replication give RPOs of minutes or seconds. Model them by setting the interval to the snapshot or replication frequency and the job run time to near zero.
• The step times are yours. The defaults for noticing, preparing and checking are our assumptions, not published figures.

Frequently asked questions

How do you calculate RPO?

The RPO itself is a target the business sets. To check whether your backups meet it, add the backup interval, the time the backup job takes and, if you would restore from an offsite copy, the time that copy takes to catch up. That is your worst-case data loss, and it needs to be no longer than the RPO.

How do you calculate RTO?

The RTO is also a target. To check it, add the time to notice the problem and decide to recover, the time to get somewhere to restore to, the restore itself (data size divided by restore speed) and the time to check the data and bring the service back. The total needs to be no longer than the RTO.

Does a nightly backup meet a 24-hour RPO?

Not quite. If the failure comes just before the next backup finishes, the newest usable backup is a full day plus the job run time old. A one-hour job gives a worst case of 25 hours, so a 24-hour RPO needs a backup at least every 23 hours.

What is the difference between RPO and RTO?

RPO is about data: the point in time to which data must be recovered, which sets the acceptable data loss. RTO is about time: the maximum acceptable delay between the interruption of a service and its restoration.

Sources

• AWS Well-Architected: disaster recovery objectives (RTO and RPO)
• NIST CSRC glossary: recovery point objective, recovery time objective and maximum tolerable downtime

Related

• RPO, RTO and MTD explained, and how to set them
• Backup storage calculator: retention, GFS and 3-2-1 copies
• How often to test a disaster recovery plan
• Immutable vs air-gapped backups

Changelog

• 27 October 2026: first release.