Backup recovery time calculator (RTO / RPO)
Enter your data volume and restore throughput to see whether your backup system can meet your recovery time objective — and what throughput you'd need if it can't.
Backup recovery time calculator
Data to restore
Restore throughput
Recovery objectives
Estimated restore time
Restore time at different sizes
How this tool works
Raw transfer time = data size ÷ throughput. Total estimated restore time adds the overhead percentage on top (for decompression, verification, and application startup). The tool compares estimated restore time against your RTO and shows whether your current setup will meet the objective. If it won't, it calculates the sustained throughput required. RPO is derived from your backup frequency — daily backups mean up to 24 hours of data could be lost in a failure between backups.
About this tool
Enter data volume, restore throughput, and your target RTO to find out whether your backup system can meet your recovery objectives. Set backup frequency to see your RPO. Includes a scenario table showing restore times at different data sizes, and calculates the throughput you'd need if you're currently failing your RTO.
Frequently asked questions
What is RTO vs RPO?
RTO (Recovery Time Objective) is how long you can afford to be down — the maximum acceptable time from incident to restored service. RPO (Recovery Point Objective) is how much data loss you can accept — measured as time, it's the maximum age of the last backup you can restore from. An RTO of 4 hours means the system must be back up within 4 hours. An RPO of 24 hours means losing up to one day of data is acceptable.
What throughput should I use?
Use the actual sustained throughput of your restore path, not the theoretical maximum. A 1 Gbps network link rarely delivers 125 MB/s end-to-end — storage IOPS, CPU decompression, and network latency all reduce effective throughput. Cloud object storage (S3, Azure Blob) typically delivers 30–80 MB/s per stream for large objects; multi-stream restores can parallelise this. Measure your actual restore speed with a test before committing to an RTO.
What does the overhead percentage represent?
Overhead accounts for the time spent on tasks beyond raw data transfer: decompression, decryption, integrity verification, database transaction log replay, application startup, and smoke-testing after restore. 20–30% is a conservative default; database restores with log replay can add 50–100% on top of transfer time.
How do I improve my RTO?
The main levers are: increase throughput (faster link, parallelise streams, local replica), reduce data volume (restore only critical systems first, tiered recovery), or reduce overhead (pre-decompressed snapshots, incremental restore). If you cannot meet RTO with a full restore, consider hot standby replicas or point-in-time snapshots that don't require a full transfer.