Backup Restore Time Calculator

Estimate how long it takes to get all your data back from where the backups live, how soon the first systems are running, and whether that fits your RTO.

Inputs

Data to restore

The size of the data once it is back on your systems (logical size). Pick TiB or GiB if the figure came from Windows, which shows binary sizes.

Where the backup lives

SaaS backup covers backups of Microsoft 365, Google Workspace and similar services. Object storage means a bucket or blob container your backup software writes to.

Restore bandwidth

The slowest link between the backup and the systems you restore to: your internet circuit or cross-connect for a cloud restore, the LAN or storage network for an on-site appliance.

Link efficiency

The share of the link that carries restored data. 90% is a planning assumption; a timed test restore gives a better number.

Per-stream limit (optional)

Some cloud and SaaS backups cap how fast one restore stream or API connection can go. If yours documents a limit, enter it with the number of streams you can run at once. Leave it empty if only the link limits you.

Parallel streams

Limit per stream

Deduplication and compression

Data reduction ratio (n:1)

What the restore sends over the link

Many cloud and SaaS restores expand the data before it leaves the provider, so the link carries every byte and the ratio doesn’t help. If your backup software restores the reduced data and expands it on site, choose the second option (stored size). Ask your provider if you’re unsure; the first is the safer assumption.

First systems back (optional)

The data you would restore first to get critical systems running, in the same unit as above.

Recovery time objective (optional)

Physical shipment time (optional)

If your provider can send the data on a drive or appliance: the whole time from request to data loaded on site, including export, shipping both ways if needed, and copying it off the device.

Result

Enter the data to restore and the restore bandwidth to see how long it takes.

Related Tools

RPO and RTO Calculator
Set how much data and time you can afford to lose for each system, and see what kind of protection that takes.
Replication Bandwidth Calculator
Find out how much bandwidth you need to copy changed data to a second site or the cloud and meet your recovery point target.
Backup Storage Calculator
See how much storage your backup retention policy needs and what it will cost each month at your quoted prices.
Uptime and SLA Calculator
See how much downtime an uptime percentage really allows, and what an outage is worth in SLA credits.
Data Transfer Time Calculator
Find out how long it will take to move your data over a network link, or how fast a link you need to hit a deadline.

How the calculation works

Restore time = rehydration wait + data moved × 8 ÷ throughput.

Throughput is the lower of two limits: the restore bandwidth × link efficiency, and the number of parallel streams × the per-stream limit (when you enter one). The results show which one is the bottleneck. Efficiency applies to the link only; a per-stream limit is taken as a data rate the provider or appliance delivers, so it isn’t reduced further.
Data moved is the full (logical) size by default: what the data takes up once it’s back on your systems. If your restore moves the stored, deduplicated and compressed data and expands it at your end, choose that option and the data moved is the size ÷ the reduction ratio.
Rehydration wait only applies to an archive storage tier: the time from asking for the data to being able to read it. It is added to both the full restore and the first systems back.
First systems back uses the same throughput and wait for the smaller amount you enter.

Units. Decimal sizes use powers of 1,000 (1 TB = 10¹² bytes); binary sizes use powers of 1,024 (1 TiB = 2⁴⁰ bytes). Link speeds are decimal (1 Gbps = 10⁹ bits per second), and 1 MB/s is 8 Mbps.

The comparisons use your numbers. The RTO comparison says how far inside or past your target each time lands. The shipment comparison sets your end-to-end shipping time against the full network restore. No provider speeds, limits or shipping times are built in.

The estimate assumes a steady rate for the whole restore. It leaves out the time to rebuild servers, the restore software’s own processing, many small files (which can be far slower than large ones), and the storage you restore to. Treat it as the shortest the restore could take, then check it against a timed test.

Worked example

20 TB from a cloud backup service over 1 Gbps. At 90% efficiency the throughput is 900 Mbps (112.5 MB/s), and the restore moves the full 20 TB:

20 TB × 8 = 1.6 × 10¹⁴ bits ÷ 900,000,000 bits per second = 177,778 seconds = about 2 days 1 h 23 min (49.38 hours)
The first 2 TB is back in 17,778 seconds, about 4 h 56 min
Against a 24-hour RTO, the full restore lands 1 day 1 h 23 min past it; the first systems land 19 h 4 min inside it
A 3-day shipment would lose: the network restore beats it by about 22 h 37 min

100 TB from an archive tier. Over the same 1 Gbps link, with a 12-hour rehydration wait, the transfer takes 888,889 seconds; with the wait, about 10 days 18 h 55 min. If the provider could deliver the data on a device in 5 days end to end, shipping would be faster by about 5 days 18 h 55 min.

When a stream limit binds. Restoring 5 TB from a SaaS backup with 4 streams limited to 20 MB/s each caps throughput at 4 × 20 MB/s × 8 = 640 Mbps, below the 900 Mbps the 1 Gbps link could carry. The restore takes 5 × 10¹² × 8 ÷ 640,000,000 = 62,500 seconds, about 17 h 22 min, and a faster circuit wouldn’t change it. The stream figures here are an illustration; use the limits your provider documents.

Frequently Asked Questions

Why does a full restore take so much longer than the nightly backup?

After the first full backup, most backups are incremental: each night sends only what changed. A full restore has to bring back everything at once, usually over the same internet circuit. The calculator times the whole data set, which is what a ransomware attack or the loss of a site asks for.

Does deduplication make a restore faster?

Only when the restore moves the reduced data and expands it at your end. Many cloud and SaaS restores expand the data at the provider before it leaves, so the link carries every byte and the ratio doesn't help. The calculator lets you choose either case; if you don't know which yours does, assume the full size and ask your provider.

What is rehydration on an archive storage tier?

Archive tiers keep data in a form that can't be read straight away. You ask for it back, wait for the retrieval to finish, and only then can the download start. Providers document the wait for each retrieval option, and faster options usually cost more. Enter the wait for the option you'd use; it adds to the full restore and to the first systems.

Should we ask the provider to ship our data on a device instead?

Compare the two times. If the network restore runs to days and your provider offers export on a drive or appliance, the device can win, as long as you count the whole chain: the request, copying the data out, shipping and loading it on site. Check ahead of an incident whether the service is offered for your backups, how long it takes and what it costs.

What belongs in the first systems back?

The smallest set that lets the business run: usually identity and name services, the core business applications and their databases, and whatever they depend on. Restoring those first, then the rest, is how many recovery plans meet an RTO that a full restore can't. Size that subset from your backup reports and enter it to see when it would be running.

How do we get a real restore time instead of an estimate?

Time a test restore of a few hundred gigabytes from the same backup location, over the same path, to the same kind of storage. Divide the data by the time to get your real throughput, and use it as the link speed with 100% efficiency. Repeat the test after changes to the link, the backup software or the provider.