Artikel | 28. May 2026
Recovery Time Objective: How to Calculate Your RTO Realistically
What Is RTO? Definition #
RTO () = the maximum acceptable downtime for a system following an incident.
Examples:
- “Our domain must be restored within 2 hours. Therefore: RTO = 2 hours.”
- “Our file server can be offline for 24 hours. Therefore: RTO = 24 hours.”
RTO vs. RPO (an important distinction):
- RTO: How long can the system be offline? (downtime)
- RPO (): How much data loss is acceptable? (how old can the last backup be?)
RTO is also a compliance metric: NIS2 (Directive (EU) 2022⁄2555) requires demonstrable disaster recovery, Art. 32 requires the ability to restore availability of personal data in a timely manner, and requires financial entities to test their recovery capability.
BIA Methodology: How to Calculate RTO Correctly #
BIA = Business Impact Analysis.
The BIA is the correct method for defining RTO. It is based on actual business impact, not technical estimates.
Step 1: Define System Criticality #
Rate each system based on how critical it is to the business. An illustrative assessment (your numbers will differ):
- Domain Controller: highly critical; all users cannot log in; assume EUR 50,000 loss per hour
- Email server: highly critical; communications stop; assume EUR 30,000 per hour
- ERP system: critical; orders cannot be processed; assume EUR 100,000 per hour
- File server: critical; documents inaccessible; assume EUR 20,000 per hour
- Backup system itself: highly critical; without it, a future incident is not recoverable
- Reporting database: normal; reports delayed, business continues; assume EUR 1,000 per hour
Step 2: Calculate Maximum Tolerable Downtime (MTD) #
MTD = the maximum downtime before the business loss becomes unacceptable.
Formula: MTD = acceptable total loss divided by business loss per hour.
Example for the Domain Controller:
- Business loss: EUR 50,000 per hour
- Acceptable total loss for this incident: EUR 200,000
- MTD = 200,000 / 50,000 = 4 hours
Therefore: the Domain Controller must be restored within 4 hours.
Step 3: RTO = MTD Minus Buffer #
The RTO should be smaller than the MTD, to leave a safety margin:
RTO = MTD times 0.75 (a 25% safety buffer).
Example:
- MTD for the Domain Controller: 4 hours
- RTO = 4 x 0.75 = 3 hours
You target a 3‑hour recovery but have 4 hours before the situation becomes uncontrollable.
Typical RTO Values by System Category #
Realistic RTO guidelines based on industry experience, by criticality (highly critical / critical / normal):
- Domain Controller: 1 to 2 hours / 2 to 4 hours / 8 to 24 hours
- Email: 2 to 4 hours / 4 to 8 hours / 24 hours
- ERP: 4 to 8 hours / 8 to 24 hours / 24 to 48 hours
- File server: 2 to 4 hours / 8 to 24 hours / 48 hours or more
- External web server: 1 to 2 hours / 4 to 8 hours / 24 hours
- Test/dev environment: 1 to 7 days regardless of category
- Backup system: 1 hour / 2 to 4 hours / 8 hours
Rule of thumb: the more critical the system, the smaller the RTO.
How to Calculate RTO: Practical Formula #
For each system, the RTO must cover the worst applicable path:
RTO = the maximum of hardware recovery time (procurement, installation), software recovery time (OS installation, configuration), data recovery time (backup restore), and testing/validation time, plus a 30% buffer.
Example: Domain Controller #
Hardware recovery (if hardware fails):
- Procure replacement hardware: 4 hours
- Installation: 1 hour
- Total: 5 hours
Software and data recovery (if only data is corrupted):
- Retrieve backup from the air gap tier: 0.5 hours
- Run the restore: 1 hour
- Validate the AD database: 1 hour
- Total: 2.5 hours
Worst case: max(5 h, 2.5 h) = 5 hours. With a 30% buffer: 6.5 hours.
Therefore: RTO for the Domain Controller = 6.5 hours if a genuine hardware failure is in scope.
But: with standby hardware and a backup, you can recover without procurement:
- With good backups and standby capacity: RTO = 2.5 hours
- Without: RTO = 6.5 hours
RTO Testing: The Critical Step #
Common mistake: RTO is “estimated,” not “tested.” This is a significant risk, and for entities under it is also a compliance gap, because resilience testing is mandatory there.
How to Test RTO #
Conduct a recovery test:
- Prepare a test environment (not production)
- Define the recovery scenario
- Start the stopwatch
- Start the backup restore
- Validate the system (does it actually work?)
- Stop the stopwatch and record the total time
Example test, Domain Controller recovery:
- 14:00: Start, system is offline, restore initiated
- 14:15: Backup data copied from the (15 minutes)
- 14:30: Restore running on the recovery server (15 minutes)
- 15:00: AD database mounts, services start (30 minutes)
- 15:15: Test: user login works (15 minutes)
- 15:20: Validation: AD replication with other DCs OK (5 minutes)
Measured RTO: 1 hour 20 minutes. Planned RTO: 2 hours. Result: test passed.
Common RTO Test Mistakes #
Mistake 1: Testing on the same hardware as production. If the hardware itself fails, you need replacement hardware. Testing on the same hardware does not simulate this. Correct: test on different hardware to simulate procurement time.
Mistake 2: Testing without full validation. “Backup loads, therefore RTO = 30 minutes,” but login does not work or the database is corrupted. Correct: full functional test after the restore (login, transactions, replication).
Mistake 3: Testing only the favourite systems. File servers are also critical and must also be tested. Correct: recovery tests for ALL critical systems.
Mistake 4: Testing once per year, results not documented. After a year: “We tested last year, but what were the results?” Correct: document tests, archive results, repeat on a fixed schedule.
RTO vs. Recovery Reality #
A realistic comparison of recovery durations:
- Domain Controller (planned RTO 2 h): without usable backups 24 to 48 hours (hardware, rebuild); with a 1 to 2 hours
- Email (planned RTO 4 h): without usable backups 48 hours or more; with a 2 to 4 hours
- ERP database, 100 GB (planned RTO 8 h): without usable backups a week or more; with a 4 to 8 hours
- File server, 1 TB (planned RTO 4 h): without usable backups 2 to 4 weeks; with a 4 to 12 hours
Conclusion: without isolated backups and without a plan, recovery is a disaster. With a on fast secondary storage, it is a controlled process.
Frequently Asked Questions #
Is an RTO of 1 hour realistic? For highly critical systems, yes, with automated failover. But you need redundant hardware (active-active), automated snapshots instead of manual backups, and fast disk-based secondary storage.
What if our RTO is unrealistic? You need to improve one of four things: faster backup infrastructure (a on disk-based secondary storage instead of a plain NAS), redundant hardware (if hardware failure is the RTO killer), automation (eliminate manual steps), or training (faster recovery through routine).
Does every system need an RTO? Yes, but with different values: critical systems 1 to 8 hours, important systems 24 to 48 hours, test/dev 1 to 7 days.
Checklist: Calculate and Test RTO Correctly #
- Conduct a BIA (MTD for each critical system)
- Define the RTO per system (MTD times 0.75)
- Estimate hardware recovery time (procurement, installation)
- Estimate backup recovery time (restore, validation)
- Total RTO = worst path plus buffer
- Conduct a recovery test with time measurement
- Document the test results
- Analyse deviations (is the RTO realistic?)
- Repeat recovery tests on a fixed schedule
- Inform executive management about the RTO and obtain sign-off
Further Resources #
→ Recovery Checklist: 12 Steps After an Attack (/en/blog/ransomware-recovery-checkliste/) → Incident Response for : Who Does What? (/en/blog/incident-response-ransomware/) → Defining RTO and RPO Correctly (/en/blog/rto-rpo-definieren/) → Hardware : Comparison for IT Decision-Makers (/en/blog/hardware-air-gap-vergleich/) → Silent Brick System: Hardware for Fast Recovery (/en/produkte/silent-brick-system/) → Request a Demo (/en/kontakt/demo/)
RTO / RPO
RTO (Recovery Time Objective) is the maximum acceptable downtime after an IT failure; RPO (Recovery Point Objective) is the maximum acceptable data loss — both are metrics that must be technically demonstrably met in backup architectures and must not merely be defined as aspirational targets.
GDPR
The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing).
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting.
Air Gap
An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting.
Air Gap
An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers.
Air Gap
An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers.
Ransomware
Ransomware is malware that encrypts data on infected systems and demands a ransom for decryption — with the goal of forcing organizations and public bodies to pay by paralyzing their operations.
Ransomware
Ransomware is malware that encrypts data on infected systems and demands a ransom for decryption — with the goal of forcing organizations and public bodies to pay by paralyzing their operations.
Air Gap
An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers.
Air Gap
An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers.
RTO / RPO
RTO (Recovery Time Objective) is the maximum acceptable downtime after an IT failure; RPO (Recovery Point Objective) is the maximum acceptable data loss — both are metrics that must be technically demonstrably met in backup architectures and must not merely be defined as aspirational targets.
Air Gap
An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers.
Air Gap
An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers.
Air Gap
An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers.
Air Gap
An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers.
Air Gap
An air gap is the complete physical interruption of all network connections between a backup system and the rest of the IT infrastructure, so that the system has no addressable network interface in its offline state and is therefore unreachable by ransomware and attackers.