How it is calculated
| Transfer time | GB × 8 × 109 ÷ (Mbit/s × 106 × efficiency) seconds |
|---|---|
| Recovery time | transfer time + fixed steps |
| Worst-case data loss | backup interval + backup run time (a failure just before a backup completes loses everything since the previous one) |
| Speed needed | data ÷ (RTO − fixed steps), adjusted for efficiency |
RTO and RPO follow the definitions in NIST SP 800-34 Rev. 1. The backup and recovery guide covers 3-2-1 copies, immutability and restore drills.
Worked example
Worked example
2,000 GB over 1 Gbit/s at 70% efficiency: 2,000 × 8,000 ÷ 700 = 22,857 seconds, or 6.35 hours. Add 90 minutes of fixed steps: 7.85 hours, inside an 8-hour RTO with little margin. Daily backups that take 2 hours give a worst case of 26 hours of lost data, which misses a 24-hour RPO.
Assumptions and limits
- Assumes the restore source is reachable and intact. Ransomware that reaches backup credentials breaks this assumption: keep an immutable or offline copy.
- Database restores often need a replay or index rebuild after the copy; include it in fixed steps.
- The only way to know your real recovery time is a timed restore drill.
How we test this tool
Unit tests check the example above (6.35 h transfer, 7.85 h total, 26 h worst-case loss, 977 Mbit/s needed) and that an RTO shorter than the fixed steps returns “not possible” instead of a number.
Frequently asked questions
What is the difference between RTO and RPO?
RTO is how long you can be down; RPO is how much recent data you can afford to lose, measured in time.
How do I shorten recovery time?
Restore from a copy closer to the target, keep a warm standby, restore the most important data first, or reduce fixed steps by automating provisioning.
Sources
Related
Inputs stay in your browser. Tool maths last reviewed ; the unit tests that pin these formulas are listed in the evidence hub.