Recovery Time Objective: So berechnen Sie Ihr RTO realistisch

Was ist RTO? Defi­ni­ti­on #

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 = 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 #

Bewer­ten Sie jedes Sys­tem danach, wie kri­tisch es für das Busi­ness ist:

Sys­tem	Kri­ti­k­ali­tät	Geschäfts-Impact pro Stun­de Ausfallzeit
**Domain Con­trol­ler**	Hoch­kri­tisch	Alle User kön­nen sich nicht anmel­den → 50.000 EUR/​h Ausfall
**E‑Mail-Ser­ver**	Hoch­kri­tisch	Kom­mu­ni­ka­ti­on stoppt → 30.000 EUR/​h
**ERP-Sys­tem**	Kri­tisch	Bestel­lun­gen kön­nen nicht ver­ar­bei­tet wer­den → 100.000 EUR/​h
**File­ser­ver**	Kri­tisch	Doku­men­te nicht erreich­bar → 20.000 EUR/​h
**Back­up-Sys­tem selbst**	Hoch­kri­tisch	Kei­ne Back­ups mög­lich → spä­ter Angriff nicht recoverable
**Daten­bank Reporting**	Nor­mal	Reports 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 #

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 #

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 #

Hier sind rea­lis­ti­sche RTO-Wer­te (basie­rend auf Branchenerfahrung):

Sys­tem	Hoch­kri­tisch	Kri­tisch	Nor­mal
**Domain Con­trol­ler**	1 – 2h	2 – 4h	8 – 24h
**E‑Mail**	2 – 4h	4 – 8h	24h
**ERP**	4 – 8h	8 – 24h	24 – 48h
**File­ser­ver**	2 – 4h	8 – 24h	48h+
**Web-Ser­ver (extern)**	1 – 2h	4 – 8h	24h
**Tes­t/­Dev-Umge­bung**	—	—	1 – 7 Tage
**Back­up-Sys­tem**	1h	2 – 4h	8h

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 #

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 #

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 #

Häu­fi­ger Feh­ler: RTO wird ​“geschätzt”, nicht ​“getes­tet”. Das ist ein gro­ßes Risiko.

Wie man RTO tes­tet #

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 Hardware Air Gap 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 #

❌ 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 #

Hier ist ein rea­lis­ti­scher Vergleich:

Sys­tem	Geplan­tes RTO	Ohne Back­ups	Mit Tape-Back­ups	Mit Hard­ware Air Gap
**Domain Con­trol­ler**	2h	24 – 48h (Hard­ware, Neu-Setup)	4 – 8h (Tape holen)	1 – 2h ✅
**E‑Mail**	4h	48h+	8 – 12h	2 – 4h ✅
**ERP-Daten­bank (100GB)**	8h	1 Woche+	16 – 24h	4 – 8h ✅
**File­ser­ver (1TB)**	4h	2 – 4 Wochen	24 – 48h	4 – 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 #

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 #

• [ ] 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)

---