Data Architecture

RTO and RPO Calculator

Backup interval, volume and restore rate in; achievable RTO and RPO out, against the targets you claim.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Set the data size and either a backup interval or a replication lag.
  2. Set the restore throughput in GB per minute, measured on a restore you actually ran rather than quoted from a datasheet.
  3. Fill in the human steps honestly: how long before someone notices at three in the morning, and how long before someone can authorise a restore.
  4. Add your stated targets and select Calculate RTO and RPO. The summary says which lever closes the gap.

What rto and rpo calculator does

The recovery time in the policy and the recovery time you have are usually different numbers, and the gap is almost always made of the steps nobody counts. Somebody has to notice. Somebody has to decide it is an incident and authorise a restore. And somebody has to confirm the restored data is right before traffic goes back to it. The restore itself is frequently the smallest of the four.

This lays out all four steps, sums them into an achievable RTO, and works out the recovery point from either the backup interval or the replication lag. Where the backup interval sets it, both the worst case and the average are shown, because the average is the number people quote and the worst case is the one the policy is about. If you state targets, it says by how much you miss them and which lever would actually close the gap — often not the one you were about to pull.

Frequently asked questions

RTO is how long you are down: the time from the failure to being back in service. RPO is how much data you lose: the gap between your last recoverable point and the moment of failure. They are set by different things — RTO by restore speed and human latency, RPO by backup interval or replication lag — and improving one usually does nothing for the other.

Because the clock starts at the failure, not at the restore command. A failure at 02:00 that nobody sees until the 08:00 report has already spent six hours of its RTO, and the decision to declare an incident and authorise a restore is a human step with a human latency. Plans that count only the restore are typically wrong by a factor of two or more, and always in the same direction.

The worst case. The average — half the backup interval — is the number people quote, but a failure does not choose its moment, and if it happens just before the next backup you lose the whole interval. If the policy says one hour and the backups run daily, the policy is not met by an average.

From a restore you have actually run, at production scale, onto the hardware you would really use. Anything else is a datasheet number that assumes an idle system, an empty target and no contention. If you have never run one, that is the more urgent finding — an untested backup is a hypothesis, and the numbers on this page are only as good as it.