--- title: "Recovery Time Objective: So berechnen Sie Ihr RTO realistisch" date: 2026-05-28T09:35:00+02:00 author: FAST LTA canonical_url: "https://www.fast-lta.de/de/blog/recovery-time-objective-so-berechnen-sie-ihr-rto-realistisch" section: "Entries: Articles" --- ### Was ist RTO? Defi­ni­ti­on [\#](#was-ist-rto-definition "Was ist RTO? Definition") **RTO (Reco­very Time Objec­ti­ve)** = Die maxi­mal akzep­ta­ble Aus­fall­zeit für ein Sys­tem nach einem Störfall. **Bei­spiel:** - “Unse­re Domain muss inner­halb von 2 Stun­den wie­der­her­ge­stellt sein. Also: RTO = 2 Stunden.” - “Unser File­ser­ver kann 24 Stun­den off­line sein. Also: RTO = 24 Stunden.” **RTO vs. RPO (wich­ti­ger Unterschied):** - **RTO:** Wie lan­ge darf das Sys­tem off­line sein? (Aus­fall­zeit) - **RPO:** Wie viel Daten­ver­lust ist akzep­ta­bel? (wie alt sind die letz­ten Daten?) --- ### BIA-Metho­dik: Wie Sie RTO wirk­lich berech­nen [\#](#bia-methodik-wie-sie-rto-wirklich-berechnen "BIA-Methodik: Wie Sie RTO wirklich berechnen") **BIA = Busi­ness Impact Analysis** BIA ist die **rich­ti­ge Metho­de**, um RTO zu defi­nie­ren. Sie basiert auf ech­tem Geschäftsim­pact, nicht auf tech­ni­schen Schätzungen. #### Schritt 1: Kri­ti­k­ali­tät der Sys­te­me defi­nie­ren [\#](#schritt-1-kritikalit%C3%A4t-der-systeme-definieren "Schritt 1: Kritikalität der Systeme definieren") Bewer­ten Sie jedes Sys­tem danach, wie kri­tisch es für das Busi­ness ist: Sys­temKri­ti­k­ali­tätGeschäfts-Impact pro Stun­de Ausfallzeit\*\*Domain Con­trol­ler\*\*Hoch­kri­tischAlle User kön­nen sich nicht anmel­den → 50.000 EUR/​h Ausfall\*\*E‑Mail-Ser­ver\*\*Hoch­kri­tischKom­mu­ni­ka­ti­on stoppt → 30.000 EUR/​h\*\*ERP-Sys­tem\*\*Kri­tischBestel­lun­gen kön­nen nicht ver­ar­bei­tet wer­den → 100.000 EUR/​h\*\*File­ser­ver\*\*Kri­tischDoku­men­te nicht erreich­bar → 20.000 EUR/​h\*\*Back­up-Sys­tem selbst\*\*Hoch­kri­tischKei­ne Back­ups mög­lich → spä­ter Angriff nicht recoverable\*\*Daten­bank Reporting\*\*Nor­malReports ver­zö­gert sich, Busi­ness läuft → 1.000 EUR/​h#### Schritt 2: Maxi­mum Tole­ra­ble Down­ti­me (MTD) berech­nen [\#](#schritt-2-maximum-tolerable-downtime-mtd-berechnen "Schritt 2: Maximum Tolerable Downtime (MTD) berechnen") **MTD** = Die maxi­mal tole­ra­ble Aus­fall­zeit, bis der Geschäfts­ver­lust uner­träg­lich wird. **For­mel:** ``` MTD = (Geschäftsverlust pro Stunde) / (Akzeptable Verlust-Schwelle) ``` **Bei­spiel Domain Controller:** - Geschäfts­ver­lust: 50.000 EUR/​h - Akzep­ta­bler Gesamt­ver­lust: 200.000 EUR (für die­sen Angriff) - MTD = 200.000 / 50.000 = **4 Stun­den** Also: Domain Con­trol­ler muss inner­halb von 4 Stun­den wie­der­her­ge­stellt sein. #### Schritt 3: RTO = MTD minus Puf­fer [\#](#schritt-3-rto-mtd-minus-puffer "Schritt 3: RTO = MTD minus Puffer") Das RTO soll­te **klei­ner** als MTD sein, damit Sie noch ein Sicher­heits­pols­ter haben: ``` RTO = MTD × 0,75 (25% Sicherheitspuffer) ``` **Bei­spiel:** - MTD für Domain Con­trol­ler: 4 Stunden - RTO = 4 × 0,75 = **3 Stun­den** Sie stre­ben also 3 Stun­den Reco­very an, haben aber 4 Stun­den Zeit, bevor Geschäft unkon­trol­lier­bar wird. --- ### Typi­sche RTO-Wer­te nach Sys­tem­ka­te­go­rie [\#](#typische-rto-werte-nach-systemkategorie "Typische RTO-Werte nach Systemkategorie") Hier sind rea­lis­ti­sche RTO-Wer­te (basie­rend auf Branchenerfahrung): Sys­temHoch­kri­tischKri­tischNor­mal\*\*Domain Con­trol­ler\*\*1 – 2h2 – 4h8 – 24h\*\*E‑Mail\*\*2 – 4h4 – 8h24h\*\*ERP\*\*4 – 8h8 – 24h24 – 48h\*\*File­ser­ver\*\*2 – 4h8 – 24h48h+\*\*Web-Ser­ver (extern)\*\*1 – 2h4 – 8h24h\*\*Tes­t/­Dev-Umge­bung\*\*——1 – 7 Tage\*\*Back­up-Sys­tem\*\*1h2 – 4h8h**Merk­re­gel:** Je kri­ti­scher das Sys­tem, des­to klei­ner das RTO. --- ### Wie man RTO berech­net: Prak­ti­sche For­mel [\#](#wie-man-rto-berechnet-praktische-formel "Wie man RTO berechnet: Praktische Formel") Für jedes System: ``` RTO = max( Hardware-Recovery-Zeit (Beschaffung, Installation), Software-Recovery-Zeit (OS-Installation, Konfiguration), Daten-Recovery-Zeit (Backup-Restore), Test-und-Validierungs-Zeit ) + 30% Puffer ``` #### Bei­spiel: Domain Con­trol­ler [\#](#beispiel-domain-controller "Beispiel: Domain Controller") **Hard­ware-Reco­very (wenn Hard­ware defekt):** - Ersatz-Hard­ware beschaf­fen: 4h - Instal­la­ti­on: 1h - Total: 5h **Soft­ware-Reco­very (wenn nur Daten kaputt):** - Back­up aus Air Gap holen: 0,5h - Res­to­re durch­füh­ren: 1h - AD-Daten­bank vali­die­ren: 1h - Total: 2,5h **Worst Case:** Max(5h, 2,5h) = 5h **Mit 30% Puf­fer:** 5h × 1,3 = **6,5 Stun­den** Also: RTO für Domain Con­trol­ler = 6,5 Stun­den (wenn Sie ein ech­tes Hard­ware-Pro­blem haben) **Aber:** Wenn Sie gutes Back­up-Sys­tem haben (Hard­ware Air Gap, Snapshots), kön­nen Sie ohne Hard­ware-Beschaf­fung auskommen: - **Mit guten Back­ups:** RTO = 2,5h - **Ohne gute Back­ups:** RTO = 6,5h --- ### RTO-Test: Der kri­ti­sche Punkt [\#](#rto-test-der-kritische-punkt "RTO-Test: Der kritische Punkt") **Häu­fi­ger Feh­ler:** RTO wird ​“geschätzt”, nicht ​“getes­tet”. Das ist ein gro­ßes Risiko. #### Wie man RTO tes­tet [\#](#wie-man-rto-testet "Wie man RTO testet") **Reco­very-Test durchführen:** 1. **Test-Umge­bung vor­be­rei­ten** (nicht Produktion!) 2. **Sys­tem off­line neh­men** (für Recovery-Test) 3. **Stop­watch star­ten** (Zeit­mes­sung!) 4. **Back­up star­ten** (Res­to­re aus Back­up durchführen) 5. **Sys­tem vali­die­ren** (Funk­tio­niert es wirklich?) 6. **Stop­watch stop­pen** (Gesamt­zeit messen) **Bei­spiel-Test: Domain Con­trol­ler Recovery** ``` 14:00:00 - Start: System ist offline, Restore wird gestartet 14:15:00 - Backup-Daten werden aus kopiert (15 Min) 14:30:00 - Restore auf neuen Server läuft (15 Min) 15:00:00 - AD-Datenbank mountet, Services starten (30 Min) 15:15:00 - Test: User-Login funktioniert (15 Min) 15:20:00 - Validierung: AD-Replikation mit anderen DCs okay (5 Min) TOTAL RTO GEMESSEN: 1 Stunde 20 Minuten GEPLANTE RTO: 2 Stunden ERGEBNIS: ✅ Test bestanden (unter dem Limit) ``` #### Häu­fi­ge RTO-Test-Feh­ler [\#](#h%C3%A4ufige-rto-test-fehler "Häufige RTO-Test-Fehler") **❌ Feh­ler 1: Test auf der­sel­ben Hard­ware wie Produktion** Wenn die Hard­ware selbst aus­fällt, brau­chen Sie Ersatz-Hard­ware. Das Test auf glei­cher Hard­ware nicht ab. **✅ Rich­tig:** Test auf **ande­rer Hard­ware**, um Beschaf­fungs­zeit zu simulieren. **❌ Feh­ler 2: Test ohne voll­stän­di­ge Validierung** ​“Back­up lädt, also RTO = 30 Minu­ten” — aber Log­in funk­tio­niert nicht, Daten­bank ist beschä­digt, etc. **✅ Rich­tig:** Voll­stän­di­ger Funk­ti­ons-Test nach Res­to­re (Log­in, Trans­ak­tio­nen, Repli­ka­ti­on, etc.) **❌ Feh­ler 3: Test nur auf kri­ti­schen Sys­te­men, nicht auf anderen** File­ser­ver auch cri­ti­cal — muss auch getes­tet werden! **✅ Rich­tig:** Reco­very-Tests für **ALLE kri­ti­schen Sys­te­me**, nicht nur die Lieblinge. **❌ Feh­ler 4: Test 1x pro Jahr, Ergeb­nis­se nicht dokumentiert** Nach einem Jahr: ​“Wir haben letz­tes Jahr getes­tet, aber wer weiß wel­che Ergebnisse?” **✅ Rich­tig:** Tests doku­men­tie­ren, Ergeb­nis­se archi­vie­ren, jähr­lich wiederholen. --- ### RTO vs. Reco­very-Wirk­lich­keit [\#](#rto-vs-recovery-wirklichkeit "RTO vs. Recovery-Wirklichkeit") Hier ist ein rea­lis­ti­scher Vergleich: Sys­temGeplan­tes RTOOhne Back­upsMit Tape-Back­upsMit Hard­ware Air Gap\*\*Domain Con­trol­ler\*\*2h24 – 48h (Hard­ware, Neu-Setup)4 – 8h (Tape holen)1 – 2h ✅\*\*E‑Mail\*\*4h48h+8 – 12h2 – 4h ✅\*\*ERP-Daten­bank (100GB)\*\*8h1 Woche+16 – 24h4 – 8h ✅\*\*File­ser­ver (1TB)\*\*4h2 – 4 Wochen24 – 48h4 – 12h ✅**Fazit:** Ohne Back­ups + ohne Plan = Kata­stro­phe. Mit Hard­ware Air Gap = kon­trol­lier­te, schnel­le Recovery. --- ### Häu­fi­ge Fra­gen [\#](#h%C3%A4ufige-fragen "Häufige Fragen") **Ist ein RTO von 1 Stun­de realistisch?** Für sehr kri­ti­sche Sys­te­me ja, mit Auto­ma­ted Fail­over. Aber Sie brauchen: - Red­un­dan­te Hard­ware (aktiv-aktiv) - Auto­ma­ti­sier­te Snapshots (nicht manu­el­le Backups) - Schnel­le Spei­cher (kein Tape) **Was ist, wenn unser RTO unrea­lis­tisch ist?** Dann müs­sen Sie ausbessern: 1. Schnel­le­re Back­up-Infra­struk­tur (Hard­ware Air Gap, nicht nur NAS) 2. Red­un­dan­te Hard­ware (falls Hard­ware-Aus­fall das RTO-Kil­ler ist) 3. Auto­ma­ti­sie­rung (kei­ne manu­el­len Steps) 4. Schu­lung (schnel­le­re Reco­very durch Routine) **Muss jedes Sys­tem ein RTO haben?** Ja, aber unterschiedlich: - Kri­ti­sche Sys­te­me: RTO 1 – 8h - Wich­ti­ge Sys­te­me: RTO 24 – 48h - Test/​Dev: RTO 1 – 7 Tage --- ### Check­lis­te: RTO rich­tig berech­nen und tes­ten [\#](#checkliste-rto-richtig-berechnen-und-testen "Checkliste: RTO richtig berechnen und testen") - \[ \] BIA durch­füh­ren (MTD für jedes kri­ti­sche System) - \[ \] RTO pro Sys­tem defi­nie­ren (= MTD × 0,75) - \[ \] Hard­ware-Reco­very-Zeit schät­zen (Beschaf­fung, Installation) - \[ \] Back­up-Reco­very-Zeit schät­zen (Res­to­re, Validierung) - \[ \] Gesamt-RTO = Sum­me + Puffer - \[ \] Reco­very-Test mit Zeit­mes­sung durchführen - \[ \] Test-Ergeb­nis­se dokumentieren - \[ \] Abwei­chun­gen ana­ly­sie­ren (ist RTO realistisch?) - \[ \] Jähr­li­che Reco­very-Tests repetieren - \[ \] Geschäfts­füh­rung über RTO infor­mie­ren (und ihre Zustim­mung erhalten) --- ### Air Gap Ein Air Gap ist die physische Unterbrechung jeder Netzwerkverbindung zwischen einem Backup-System und der übrigen IT-Infrastruktur, sodass das System im Offline-Zustand keine adressierbare Netzwerkschnittstelle besitzt und damit für Ransomware und Angreifer unerreichbar ist. [Mehr erfahren →](https://www.fast-lta.de/de/glossar/air-gap) ### Air Gap Ein Air Gap ist die physische Unterbrechung jeder Netzwerkverbindung zwischen einem Backup-System und der übrigen IT-Infrastruktur, sodass das System im Offline-Zustand keine adressierbare Netzwerkschnittstelle besitzt und damit für Ransomware und Angreifer unerreichbar ist. [Mehr erfahren →](https://www.fast-lta.de/de/glossar/air-gap) ### Air Gap Ein Air Gap ist die physische Unterbrechung jeder Netzwerkverbindung zwischen einem Backup-System und der übrigen IT-Infrastruktur, sodass das System im Offline-Zustand keine adressierbare Netzwerkschnittstelle besitzt und damit für Ransomware und Angreifer unerreichbar ist. [Mehr erfahren →](https://www.fast-lta.de/de/glossar/air-gap) ### Air Gap Ein Air Gap ist die physische Unterbrechung jeder Netzwerkverbindung zwischen einem Backup-System und der übrigen IT-Infrastruktur, sodass das System im Offline-Zustand keine adressierbare Netzwerkschnittstelle besitzt und damit für Ransomware und Angreifer unerreichbar ist. [Mehr erfahren →](https://www.fast-lta.de/de/glossar/air-gap) ### Air Gap Ein Air Gap ist die physische Unterbrechung jeder Netzwerkverbindung zwischen einem Backup-System und der übrigen IT-Infrastruktur, sodass das System im Offline-Zustand keine adressierbare Netzwerkschnittstelle besitzt und damit für Ransomware und Angreifer unerreichbar ist. [Mehr erfahren →](https://www.fast-lta.de/de/glossar/air-gap) ### Air Gap Ein Air Gap ist die physische Unterbrechung jeder Netzwerkverbindung zwischen einem Backup-System und der übrigen IT-Infrastruktur, sodass das System im Offline-Zustand keine adressierbare Netzwerkschnittstelle besitzt und damit für Ransomware und Angreifer unerreichbar ist. [Mehr erfahren →](https://www.fast-lta.de/de/glossar/air-gap)