Backup Restore Time Estimator
Updated .
This estimator turns the size of your data and the speed you actually get when restoring into hours. It converts between bits and bytes for you, adds an allowance you choose for verification and overhead, adds setup time per system, and multiplies across the systems you restore one after another. It is an estimate: a real restore test overrides it.
How it works
The estimator uses six lines of arithmetic, all shown in the result:
- Size in megabytes = gigabytes × 1,000 (terabytes are first multiplied by 1,000 to give gigabytes).
- Speed in megabytes per second = megabits per second ÷ 8, or the speed as entered if you gave megabytes per second.
- Transfer hours = megabytes ÷ megabytes per second ÷ 3,600.
- With overhead = transfer hours × (1 + overhead ÷ 100).
- Per system = that figure + setup minutes ÷ 60.
- Total = per-system hours × the number of systems restored one after another.
Bits and bytes. A bit is the smallest unit of data, and a byte is 8 bits. Network speeds are quoted in bits per second (Mbps), while file sizes and many backup tools use bytes (MB, GB, TB). A 100 Mbps link therefore moves at most about 12.5 megabytes of data a second, before any overhead. Mixing the two is the commonest reason a restore takes eight times longer than a quick estimate suggested.
Why a test overrides this. Real restores slow down for reasons a formula cannot see: many small files, a busy backup server, encryption, throttling by a cloud provider, a slower disk at the destination. Run the steps in the restore testing guide, time a sample, then enter the measured speed here. The estimate also leaves out finding a clean backup, rebuilding systems and investigating the cause. The recovery-time planning guide covers those, and the downtime cost calculator prices the hours.
Worked example
Suppose, as a hypothetical, each of 2 systems holds 2 TB, the measured restore speed is 200 Mbps, you allow 25% for verification and overhead, and each system needs 30 minutes of setup.
Size: 2 TB = 2,000 GB = 2,000,000 MB. Speed: 200 ÷ 8 = 25 MB/s. Transfer: 2,000,000 ÷ 25 ÷ 3,600 = 22.22 hours. With overhead: 22.22 × 1.25 = 27.78 hours. Add setup: 27.78 + 0.50 = 28.28 hours per system (28 h 17 min).
Two systems one after another: 28.28 × 2 = 56.56 hours, or about 2.36 days of continuous restore. If a restore test showed the real speed was half that, the answer would roughly double, which is why a measured speed beats a guess. These numbers are illustrative arithmetic, not data about any backup product, link or business.
Frequently asked questions
Why does a 1 Gbps link not restore 1 GB in one second?
Link speed is quoted in bits, and a byte is 8 bits, so 1 Gbps is at most about 125 MB/s. Real restores also run slower than the link because of overhead, many small files, disk speed and the other traffic on the connection.
What speed should I enter?
The speed you measured in a restore test, taken from a sample of your real data. If you have no test yet, use a cautious figure well below the contract or line speed, and plan to replace it after your first test.
Does this cover ransomware recovery as a whole?
No. It estimates only the time to move data back. Finding a clean backup, rebuilding systems, checking for the attacker’s access and testing applications take extra time that the recovery-time planning guide covers.
Can restores run at the same time?
Sometimes, if they do not share the same network link, backup server or destination disk. If they do, running them together may not save much time. Enter the number you must run one after another for a cautious estimate.
Does this send my numbers anywhere?
No. The calculation runs in your browser and nothing is stored or sent.
Want the briefing in your inbox?
The briefing is published on this site every morning. The email edition is not sending yet — leave your address and you’ll be among the first told when it starts. Nothing is sent in the meantime.