# ERP Database Backup and Restore Time (RTO and RPO) Calculator

> Source: https://netray.co/tools/erp-database-backup-restore-rto-rpo-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Estimate backup size, restore time (RTO) and worst-case data loss (RPO) for an ERP database from full, differential and log backups.

## Category

erp-operations

## Audience

- ERP administrator
- DBA
- IT manager

## Tool

**Kind:** calculator

**Inputs:**

#### Database size

**Key:** db_gb

**Type:** number

**Default:** 800

**Min:** 1

**Step:** 50

**Unit:** GB

**Help:** Used data and index size, not file size.

#### Backup compression saving

**Key:** compress_pct

**Type:** slider

**Default:** 60

**Min:** 0

**Max:** 90

**Step:** 5

**Unit:** %

**Help:** ERP data often compresses 50 to 80 percent. Check backupset compressed_backup_size.

#### Backup throughput

**Key:** backup_mbps

**Type:** number

**Default:** 300

**Min:** 10

**Step:** 10

**Unit:** MB/s

**Help:** Measured read plus write throughput during backup.

#### Restore throughput

**Key:** restore_mbps

**Type:** slider

**Default:** 250

**Min:** 50

**Max:** 1000

**Step:** 10

**Unit:** MB/s

**Help:** Measured on the target storage. Restore writes the full data size.

#### Differential size

**Key:** diff_pct

**Type:** number

**Default:** 8

**Min:** 0

**Max:** 100

**Step:** 1

**Unit:** % of DB

**Help:** Share of pages changed since the last full backup.

#### Log backup volume per day

**Key:** log_gb_day

**Type:** number

**Default:** 40

**Min:** 0

**Step:** 5

**Unit:** GB/day

#### Hours of log to replay

**Key:** hours_since_diff

**Type:** number

**Default:** 6

**Min:** 0

**Step:** 1

**Unit:** hours

**Help:** Worst case hours between the last differential and the failure.

#### Log replay throughput

**Key:** replay_mbps

**Type:** number

**Default:** 120

**Min:** 10

**Step:** 10

**Unit:** MB/s

#### Log backup interval

**Key:** log_interval_min

**Type:** number

**Default:** 15

**Min:** 1

**Step:** 1

**Unit:** min

#### Fixed overhead

**Key:** overhead_min

**Type:** number

**Default:** 45

**Min:** 0

**Step:** 5

**Unit:** min

**Help:** Decision time, provisioning, DBCC checks, application startup and validation.

**Outputs:**

#### Full backup file size

**Key:** backup_gb

**Expr:** db_gb * (1 - compress_pct / 100)

**Format:** decimal

#### Full backup duration

**Key:** backup_min

**Expr:** backup_gb * 1024 / backup_mbps / 60

**Format:** minutes

#### Full restore time

**Key:** restore_full_min

**Expr:** db_gb * 1024 / restore_mbps / 60

**Format:** minutes

#### Differential restore time

**Key:** restore_diff_min

**Expr:** db_gb * diff_pct / 100 * (1 - compress_pct / 100) * 1024 / restore_mbps / 60

**Format:** minutes

#### Log replay time

**Key:** replay_min

**Expr:** log_gb_day / 24 * hours_since_diff * 1024 / replay_mbps / 60

**Format:** minutes

#### Total restore time

**Key:** rto_min

**Expr:** restore_full_min + restore_diff_min + replay_min + overhead_min

**Format:** minutes

#### Achievable RTO

**Key:** rto_hours

**Expr:** rto_min / 60

**Format:** hours

**Primary:** true

**Description:** Time from the decision to restore until the ERP is usable again.

#### Worst-case data loss (RPO)

**Key:** rpo_min

**Expr:** log_interval_min

**Format:** minutes

**Primary:** true

**Description:** With log backups only, you can lose up to one interval of transactions.

**Chart:**

#### Restore time (hours) versus restore throughput

**Type:** line

**X:** restore_mbps

**From:** 50

**To:** 800

**Steps:** 30

**Series:**

- rto_hours

**Disclaimer:** A simple sequential model. Real restores depend on storage, network, instant file initialization, parallel restore and verification. Test a full restore against your stated RTO at least annually.

## Content

**Intro:** When the ERP database dies, the first question is how long it takes to come back. This calculator turns database size, compression, storage speed and your backup chain into a restore time (RTO) and worst-case data loss (RPO), and charts the effect of faster restore storage.

**Sections:**

#### How to use it

**Body:** Enter the used database size and the compression you actually see in the msdb backupset history. Use measured throughputs, not vendor spec sheets: run a restore to a test server and note MB per second. Add how large your differential backup usually is, the daily log volume and how many hours of log you would need to replay in a bad case. The fixed overhead covers people time and checks, which is often the largest hidden item.

**Bullets:**

- Measure restore speed on the real target storage
- Use worst-case hours since the last differential
- Put human decision time into the overhead

#### RTO and RPO explained

**Body:** Recovery time objective is how long the business can wait. Recovery point objective is how much data it can afford to lose. With a full, differential and log backup chain, the restore sequence is full, then the latest differential, then each log backup up to the point of failure. RPO is bounded by the log backup interval, assuming the log backups survive the failure. The calculator adds the three restore steps and the fixed overhead to give RTO.

#### Worked example

**Body:** An 800 GB database restores at 250 MB per second in about 55 minutes. A differential of 8 percent compressed at 60 percent is about 26 GB and adds roughly 2 minutes. Six hours of 40 GB per day log adds around 6 GB and about 1 minute. With 45 minutes of overhead, RTO is a little under 2 hours. If the board expects 1 hour, the lever is restore storage or a standby copy, not a smarter backup schedule.

#### Common mistakes

**Body:** Many plans quote backup time as if it were restore time. Restore writes the entire data size and often runs slower than backup. Others forget log backups must be copied off the failed server, or assume the test environment matches production. A backup never restored is only a hope.

**Cta:** If you need restore rehearsals, backup verification reports or a standby design, we can help plan and automate them on your own infrastructure.

**Faq:**

#### Is RTO the same as the restore time?

**Answer:** Not quite. RTO is the whole time the business is down: detection, decision, provisioning, restore, checks and application restart. This tool uses the technical restore plus a fixed overhead you set so the result is closer to what users experience.

#### Why does restore take longer than backup?

**Answer:** A restore has to write the full uncompressed data and log files, and may zero-initialize files if instant file initialization is off. Backup only reads used pages and writes a compressed file. Measure both on your own hardware.

#### How does compression change the answer?

**Answer:** Compression shrinks the backup file, which speeds up backup and shortens copy time. Restore time is driven mostly by the database size written to disk, so compression helps restore less than people expect, unless storage is network-limited.

#### Can I reach a 15 minute RTO with backups only?

**Answer:** Rarely for a database of any size. For a short RTO, use a warm standby, log shipping or an availability group, and treat backups as the last line of defense and for point-in-time recovery after logical errors.

## Search terms

database restore time calculator, rto rpo calculator, erp disaster recovery restore time, how long to restore sql server database, backup size estimate compression, differential backup restore time, erp recovery time objective

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json