Skip to content

Backup and restore time calculator (RPO/RTO)

How long does your backup take, and how long would a restore take after an outage? Enter volume, bandwidth and schedule to see backup duration, worst-case RPO, an RTO estimate and the storage you need.

Free tool · Infrastructure
Data

Total production data (1 GB = 10^9 bytes).

%

Share of the volume that changes in a day; take it from your backup software's report.

: 1

2 = data halves, 1 = no reduction. The first backup without history may reduce less.

Speed

The narrowest link from source to repository (network, disk or backup server).

The slower of reading from the repository and writing to the target.

%

The share of the link you actually get; 60–80% is common to allow for protocol and sharing overhead.

The line that carries data off site or to the cloud.

Schedule and retention

How far back must the oldest recovery point go?

Last 7 days of incrementals, 4 weekly, up to 12 monthly and yearly full backups.

Targets
hours

How long a backup may run without affecting production. Leave empty to skip the check.

hours

The most data loss you can accept. Leave empty to skip the check.

hours

How soon the service must be back. Leave empty to skip the check.

hours

For OS/hardware preparation, application start-up and data validation.

Copies (3-2-1-1-0)
copies

Including the production data.

types

E.g. disk + tape, disk + object storage.

copies

At another facility or in the cloud.

copies

Object lock (WORM), tape or air-gapped copy.

A test in which the backup was actually restored and verified.

Results

Full backup time
6.3 h
Full backup size (reduced): 2 TB
Incremental backup time
3 min
Incremental backup size (reduced): 15 GB
Fits the backup window
Meets target
Full: 6.3 h · Incremental: 3 min
Worst-case RPO
6 h
Meets target
RPO while a full backup runs
12.3 h
Exceeds target
Full restore time
3.1 h
RTO estimate
5.1 h
Meets target · Full restore 2.5 h + incremental chain 32 min + rebuild/validation allowance 2 h
Storage for retention (one copy)
14.43 TB
6 full + 162 incremental backups · 30 days retention (upper-bound estimate)
For all backup copies
28.86 TB
2 backup copies (excluding production data)
Initial seeding over WAN
31.7 h
Daily change transfer over WAN
57 min

3-2-1-1-0 checklist

  • At least 3 copies (production data + 2 backups)Met
  • At least 2 different mediaMet
  • At least 1 copy off siteMet
  • At least 1 copy immutable or offlineMet
  • Restore test verified with 0 errorsMissing

4/5 items met

Calculation and units

  • Units are decimal: 1 GB = 10^9 bytes, 1 TB = 10^12 bytes, 1 Mbit/s = 10^6 bit/s. 1 byte = 8 bits.
  • Time = bytes × 8 / (bit/s × efficiency). Transferred data = volume ÷ reduction ratio.
  • Worst-case RPO = incremental interval + incremental backup duration.
  • RTO = volume/read speed + chain incrementals/read speed + rebuild allowance (the end of the chain is the worst case).

This is a preliminary estimate. Real times depend on your backup software, disk and network performance, data type (database, virtual machine, files) and concurrent jobs. Incremental sizes assume change grows linearly and therefore sit near an upper bound. For critical systems, test restores in a real environment.

Shall we review your backup design and restore scenarios together? We can validate the result against your own infrastructure.

Request a meeting

01

How to use

  1. A

    Enter the data volume, daily change rate and compression ratio; choose backup and restore speeds in bits or bytes.

  2. B

    Set full and incremental frequency, retention and, optionally, the backup window and target RPO/RTO.

  3. C

    Check whether the window is exceeded, whether RPO/RTO are met and what is missing on the 3-2-1-1-0 list; change values to compare scenarios.

02

How are RPO and RTO calculated?

RPO (recovery point objective) states the most data loss you can tolerate in an outage. In the worst case the loss is the time from when the last backup started to when it finished and became usable, so the calculation adds the incremental interval and the incremental backup duration. Where incrementals wait while a full backup runs, RPO stretches to the full backup time; that is the value shown on a separate row.

RTO (recovery time objective) is how long it takes for the service to return. The estimate adds the time to write back the latest full backup and all incrementals in the chain, plus the allowance you enter for OS preparation, application start-up and data validation. If the restore is needed at the end of the chain, that is where most incrementals pile up, and the calculation takes this worst case.

03

Units and assumptions

Network speeds are in bits and data sizes in bytes, so the tool multiplies bytes by 8. Volumes are decimal (1 GB = 10^9 bytes); the GiB/TiB display (2^30, 2^40) used by some operating systems shows a number roughly 7–9% smaller, which shortens times slightly. The efficiency field stands for protocol, encryption and sharing losses; if you have a measured throughput, enter it with 100% efficiency.

The calculation assumes daily change is spread linearly over time and that the same block does not change twice; with frequently rewritten data the real incremental is smaller. The compression/deduplication ratio is applied equally to all backups. On restore, data is written at its unreduced size. For real figures, rely on your backup software's job reports and an actual restore test.

04

Backup in an OT/SCADA environment

In industrial sites the things to back up are typically the historian database, SCADA/HMI servers and screen projects, PLC and drive programs with their configurations, network device settings and virtual machine images. PLC projects are small but should be stored with version and dependency information; the historian grows fast and makes up most of the volume.

Keeping the backup infrastructure in a zone separate from the production network, holding at least one copy offline or immutable and testing restores periodically are especially important here; when a line stops, saying "we have a backup" is not enough, the time to recover must be known. Planned downtime windows are short, so the backup window and incremental frequency should follow the line schedule.

FAQ

Is my input sent anywhere?
No. The calculation runs entirely in code in your browser; values are not sent to any server and are not stored.
What is the difference between RPO and RTO?
RPO is the most data loss you accept (looking backwards in time); RTO is how quickly the service must be back (looking forwards). They are independent targets.
What is the 3-2-1-1-0 rule?
A widely used checklist: at least 3 copies, 2 different media, 1 off-site copy, 1 immutable or offline copy and 0 errors in restore tests. It is not a certification or compliance measure, just a framework for reviewing your design.
Does the GB versus GiB difference matter?
Slightly. This tool uses 1 GB = 10^9 bytes. If your system shows GiB (1 GiB ≈ 1.074 × 10^9 bytes), the real volume is a little larger and times grow proportionally.
What efficiency value should I enter?
If you have measured real throughput, enter it and set efficiency to 100%. Otherwise 60–80% is a reasonable start; encryption, small files and a shared line can lower it.

You have backups; do you know the recovery time?

Let us design backup and disaster recovery together for your servers, storage, network and OT/SCADA environments. In a free discovery call we discuss your current state and targets.

Request a meetingExplore our infrastructure service →