Calculator inputs
Formula used
The estimate combines transfer time and operational overhead:
Tip: If your tool restores uncompressed data, keep the reduction factors at 1.0.
How to use this calculator
- Pick a restore type that matches your recovery workflow.
- Enter dataset size and the percent you actually restore.
- Set compression and dedup factors to match stored backups.
- Add caps for network, source reads, and destination writes.
- Choose streams and per-stream caps for your restore tool.
- Adjust efficiency, slowdown, and processing overhead values.
- Enter fixed minutes for queueing, validation, and cutover.
- Calculate, then compare total time against your target.
Example data
| Scenario | Stored transfer (GB) | Effective rate (MB/s) | Total restore time |
|---|---|---|---|
| Regional VM restore | 390.0 | 196 | 2h 14m 29s |
| Database point-in-time | 249.6 | 98 | 2h 36m 23s |
| Object storage retrieval | 300.0 | 48 | 3h 25m 51s |
These examples are illustrative; adjust inputs to match your environment.
Why restore time matters
Restore time measures how quickly services return after data loss. In cloud and hosting operations, it drives customer impact, incident severity, and SLA outcomes. A database restore that takes 2 hours instead of 30 minutes can multiply follow on work: replay logs, rebuild caches, and validate transactions. A consistent estimation method helps teams set realistic recovery targets, choose storage tiers, and justify automation.
What this calculator models
This calculator estimates total restore duration by separating data transfer from fixed tasks. It converts your dataset into stored transfer size using compression and dedup factors, then applies the percent you actually restore. It derives effective throughput from network, source read, destination write, and per stream limits, adjusted by efficiency and slowdown. It then adds overhead minutes for queueing, mount, decrypt, decompress, integrity checks, and cutover.
Sizing bandwidth and concurrency
Throughput is rarely equal to advertised link speed. For example, 1 Gbps theoretical is about 119 MB/s, but sustained rates may be 60 to 90 MB/s after overhead and contention. Parallel streams help when a single stream is limited by latency or CPU, but returns drop when reads or writes saturate. Use stream caps to model tools that top out at 20 to 50 MB/s per stream.
Overheads beyond data transfer
Restores include more than bytes in motion. Encryption and decompression can add 5% to 35% processing time depending on CPU and algorithm choice. Retries from throttling or timeouts often contribute another 1% to 10% in busy regions. Validation is frequently fixed time: checksum verification, consistency checks, application smoke tests, and access enablement. Capture these as fixed minutes so estimates match runbooks.
Using results for planning
Compare the estimated time against your recovery objectives and decide where to optimize. If transfer dominates, improve egress paths, raise IOPS, or place backups closer to the target region. If overhead dominates, streamline approvals, automate validation, and pre stage credentials. Run scenarios for partial restores and full rebuilds. Document assumptions and rerun after architecture changes. For best accuracy, run a test restore quarterly, record observed throughput, and tune efficiency and overhead values until the estimate matches measured timelines consistently well.
FAQs
What is restore time in this calculator?
Restore time is the estimated duration to move stored backup data to the target and complete required processing and validation steps. It includes transfer, overhead percentages, and fixed minutes you enter.
Why does effective rate use the smallest limit?
A restore can only go as fast as its bottleneck. The calculator takes the minimum of network, source read, destination write, and stream limits, then applies efficiency and slowdown to reflect real sustained performance.
How do compression and dedup factors work?
They adjust the stored transfer size. If backups are smaller than raw data, set factors below 1.0. The calculator multiplies your restored data by these factors to estimate how many gigabytes must be read and transferred.
How many parallel streams should I choose?
Start with the default and increase gradually. Add streams until the effective rate stops rising or CPU, read, or write caps are reached. Many tools scale well to 4–16 streams, then flatten.
What should I include as fixed overhead minutes?
Include queueing, snapshot mount, key retrieval, metadata scans, integrity checks, application smoke tests, DNS or load balancer changes, and any human handoffs. Use your runbook timings and refine after each test restore.
Can I model partial restores or point-in-time recovery?
Yes. Set the restore percentage to the expected slice of data, and adjust overheads for extra steps like log replay or index rebuilds. For point in time workflows, add those steps as fixed minutes.