# ERP Database Restore Time and RTO Calculator

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

## Short answer

Add up full restore, differential, log replay and validation time and see whether you meet your recovery time objective.

## Category

erp-operations

## Audience

- ERP DBA
- IT manager
- ERP administrator

## Tool

**Kind:** calculator

**Inputs:**

#### Database size

**Key:** db_gb

**Type:** number

**Default:** 500

**Min:** 1

**Step:** 10

**Unit:** GB

**Help:** Used data size to restore, not file allocation.

#### Full restore throughput

**Key:** restore_mbps

**Type:** number

**Default:** 200

**Min:** 5

**Step:** 10

**Unit:** MB/s

**Help:** Measure from a real restore test, not the disk spec sheet.

#### Differential backup size

**Key:** diff_gb

**Type:** number

**Default:** 40

**Min:** 0

**Step:** 5

**Unit:** GB

#### Log backups to replay

**Key:** log_gb

**Type:** number

**Default:** 25

**Min:** 0

**Step:** 5

**Unit:** GB

**Help:** Total size of log backups since the last differential.

#### Log replay throughput

**Key:** replay_mbps

**Type:** number

**Default:** 60

**Min:** 5

**Step:** 5

**Unit:** MB/s

**Help:** Usually slower than a full restore.

#### Validation and ERP restart

**Key:** validate_min

**Type:** number

**Default:** 45

**Min:** 0

**Step:** 5

**Unit:** minutes

**Help:** Integrity check of key tables, service start, smoke test.

#### Recovery time objective

**Key:** rto_hours

**Type:** number

**Default:** 4

**Min:** 0.5

**Step:** 0.5

**Unit:** hours

**Outputs:**

#### Full restore

**Key:** full_h

**Expr:** db_gb * 1024 / restore_mbps / 3600

**Format:** hours

#### Differential restore

**Key:** diff_h

**Expr:** diff_gb * 1024 / restore_mbps / 3600

**Format:** hours

#### Log replay

**Key:** log_h

**Expr:** log_gb * 1024 / replay_mbps / 3600

**Format:** hours

#### Total estimated recovery time

**Key:** total_h

**Expr:** full_h + diff_h + log_h + validate_min / 60

**Format:** hours

**Primary:** true

**Description:** Excludes decision time, hardware provisioning and copying backups to the target.

#### Slack against RTO

**Key:** slack_h

**Expr:** rto_hours - total_h

**Format:** hours

**Description:** Negative means the RTO is missed.

#### Share of RTO used

**Key:** rto_used

**Expr:** total_h / rto_hours * 100

**Format:** percent

**Primary:** true

**Chart:**

#### Total recovery time vs database size

**Type:** line

**X:** db_gb

**From:** 100

**To:** 3000

**Steps:** 30

**Series:**

- total_h

**Disclaimer:** An estimate for planning only. Throughput depends on storage, network, compression, encryption and parallel streams. Run an actual timed restore and use the measured figures.

## Content

**Intro:** Recovery time objective is a promise to the business, and most teams have never checked it against real numbers. This calculator adds up the restore stages so you can see whether your ERP backups can actually meet the promise.

**Sections:**

#### How to use the calculator

**Body:** Enter the size of the database, the throughput you measured during your last restore test, the size of the differential and log backups since the last full, and how long validation and ERP restart usually take. Add your RTO. The result shows each stage in hours, the total, and how much of the RTO is used. The chart sweeps database size so you can see when growth will push you past the objective.

#### The formula

**Body:** Each stage is size in gigabytes times 1,024 to get megabytes, divided by throughput in megabytes per second, divided by 3,600 for hours. Full restore and differential restore use the same throughput; log replay is usually slower because transactions are applied rather than copied. Validation time is added as a flat figure. The sum is a best case, since it assumes backups are already on fast storage next to the target server.

**Bullets:**

- Hours = GB x 1,024 / MB per second / 3,600
- Total = full + differential + log replay + validation
- Slack = RTO - total

#### Worked example

**Body:** A 500 GB database restoring at 200 MB/s takes about 0.7 hours. A 40 GB differential adds about 0.06 hours, and 25 GB of logs at 60 MB/s adds about 0.12 hours. With 45 minutes for validation and ERP restart, the total is about 1.6 hours, which uses roughly 40 percent of a four hour RTO. The same plan with a 3 TB database would take well over four hours, which the chart makes obvious.

#### What the estimate leaves out

**Body:** The number does not include the time to notice and declare an incident, to provision a server, to copy backups from offsite or cloud storage, to restore the application tier, or to reconcile data lost since the last log backup. Offsite download bandwidth is often the largest hidden cost. Add those as separate lines in your recovery plan, and treat this calculator as the database stage only.

**Cta:** If your recovery plan depends on slow tape or distant offsite copies, we can help you design a faster on-premises restore path and test it end to end.

**Faq:**

#### How do I measure restore throughput?

**Answer:** Restore a recent full backup to a test server and divide the database size by the elapsed time. SQL Server reports megabytes per second when a restore completes. Use this measured figure, not the storage specification.

#### Why is log replay slower than full restore?

**Answer:** A full restore mostly copies pages sequentially, while log replay re-applies each transaction, which involves random I/O and CPU. Heavy index maintenance days produce large logs and long replays.

#### What is a reasonable RTO for an ERP?

**Answer:** It depends on the business. A plant that can fall back to paper for a shift may accept four to eight hours. A just in time supplier may need under an hour. Set it with the business, then prove it with a timed test.

#### Can I speed up restores?

**Answer:** Use faster storage, backup compression tuned to your CPU, striped backup files restored in parallel, instant file initialization for data files, and keep backups close to the target server. Each change should be re-measured in a test.

## Search terms

database restore time calculator, rto calculator, how long to restore sql server database, erp disaster recovery time, recovery time objective calculator, backup restore throughput, sql server log replay time, erp downtime estimate

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