ERP OperationsFree calculatorPDF, Excel, Word export

Ransomware Recovery Time Objective Calculator

How long would it really take to bring the plant back after ransomware? This calculator adds decision time, server rebuilds, data restore and validation into a total, so your recovery objective is based on arithmetic rather than hope.

Your numbers

TB

Total size of the systems restored from backup.

Gbps

Measured in a restore test, not link speed.

Include domain controllers, ERP, MES and file servers.

hours
3
hours

Time to confirm scope, isolate and get approval to restore.

hours

Your results

Estimated total recovery time
66 hrs
Assumes rebuild and restore run in sequence.
Total in days
3 days
Data restore time
11 hrs
1 TB is about 8,000 gigabits.
Server rebuild time
27 hrs
Share of time spent restoring data
16.9%

A planning estimate with simplifying assumptions. Real recoveries hit surprises such as missing credentials, certificates, and dependencies. Validate with an actual restore test.

Save results:

Total recovery hours vs restore throughput

Sweeps Effective restore throughput from 1 to 20, holding your other inputs fixed.

Check your recovery order

Optional review of recovery sequence and dependencies for ERP and MES.

Optional. The tool and every export work without this. No spam.

How to use the calculator

Enter the data you would restore from backup, the throughput measured in a real restore test, how many servers need rebuilding and how many people can work in parallel. Add the time it takes to decide, contain and begin, plus validation time for applications. The result shows hours and days, and the chart shows how throughput changes the total.

  • Use measured throughput, not link speed
  • Count identity and network servers first
  • Be honest about decision time
  • Add validation time for ERP and MES

The method

Restore time is data in gigabits divided by throughput in gigabits per second. Rebuild time is servers times hours each, divided by parallel teams. Total time is decision, rebuild, restore and validation added in sequence. This is conservative because some work can overlap, but dependencies such as directory services before applications often force sequence.

Reading the result

If the total exceeds the tolerance of production and customers, the biggest lever is usually not backup speed. Look at the share of time spent restoring data. If it is small, improve decision readiness, automate server builds or tier restore by priority. If it is large, improve throughput or restore critical systems first.

Common mistakes

Using the backup vendor's maximum speed, forgetting that the attacker may have encrypted the backup tier, ignoring staff fatigue, and counting only the ERP database instead of the identity and network layers that must return before it.

Frequently Asked Questions

Why is real recovery slower than the estimate?

Surprises add time: missing credentials, expired certificates, undocumented dependencies, damaged backups, and people working long hours. Treat the estimate as a floor and test to see how far above it you land.

What throughput should I enter?

The rate measured in a restore test of a comparable system to the same destination, including decryption, dedupe rehydration and network limits. Vendor maximums are rarely achieved in an incident.

Can restores run in parallel?

Often yes for independent systems, which would shorten the total. Directory services and networking usually must come first. Use the sequential total as a cautious figure and adjust once you know your dependencies.

How do I shorten recovery?

Restore in priority order, keep immutable or offline copies near the recovery site, pre-build gold images, rehearse the process, and agree decision authority in advance. Faster storage only helps if restore is the bottleneck.

If you want a recovery plan with systems ordered by dependency, we can help build one. The calculator is free and complete.