--- title: "Recovery-Runbook: Was hineingehört und wer es pflegt" date: 2026-05-27T16:10:00+02:00 author: FAST LTA canonical_url: "https://www.fast-lta.de//de/blog/recovery-runbook-was-hineingehört-und-wer-es-pflegt" section: "Entries: Articles" --- ### Was in ein Reco­very-Run­book gehört [\#](#was-in-ein-recovery-runbook-geh%C3%B6rt "Was in ein Recovery-Runbook gehört") #### Für jedes kri­ti­sche Sys­tem [\#](#f%C3%BCr-jedes-kritische-system "Für jedes kritische System") Ein Run­book soll­te pro kri­ti­schem Sys­tem auf­ge­baut wer­den. Als Bei­spiel: ​“Micro­soft Acti­ve Direc­to­ry Reco­very Run­book” oder ​“SAP ERP Reco­very Runbook”. **1. Sys­tem-Über­sicht (1 Seite)** - Name, Zweck, Business-Owner - Abhän­gi­ge Sys­te­me (Was braucht die­ses Sys­tem um zu lau­fen? z.B. AD, File­ser­ver, Netzwerk) - Abhän­gi­ge Sys­te­me (Wel­che Sys­te­me hän­gen von die­sem Sys­tem ab? z.B. alle Cli­ents brau­chen AD) - **Kri­tisch:** Wie­der­her­stel­lungs­rei­hen­fol­ge. Acti­ve Direc­to­ry muss z.B. VOR den Exch­an­ge-Ser­vern wie­der­her­ge­stellt werden. **2. RTO/RPO Definitionen** - RTO (Reco­very Time Objec­ti­ve): Wie lan­ge darf der Aus­fall dau­ern? z.B. ​“AD RTO: 2 Stunden” - RPO (Reco­very Point Objec­ti­ve): Wie viel Daten­ver­lust ist akzep­ta­bel? z.B. ​“AD RPO: 1 Stun­de” (bedeu­tet: wir kön­nen 1 Stun­de an Pass­wort-Ände­run­gen verlieren) **3. Back­up-Stand­or­te und Zugriff** - Wo sind die Back­ups die­ses Sys­tems gespei­chert? (Tier 1 Online, Tier 2 Air-Gap, Tier 3 WORM) - Wie grei­fe ich auf die Back­ups zu? (IP-Adres­se, Port­num­mer, Zugangsweg) - Wer hat Admin-Zugriff auf das Back­up-Sys­tem? (Name, Tele­fon, auch als Papier-Backup) - Was ist das Back­up-Ver­wal­tungs-Tool? (z.B. Vee­am, Bacu­la, Commvault) **4. Wie­der­her­stel­lungs-Schrit­te (Num­me­riert, detailliert)** Bei­spiel für ​“Win­dows Ser­ver Recovery”: ``` 1. Boot Recovery-Server aus ISO (Silent Brick Recovery Media oder Backup-Software ISO) 2. Wähle das Backup aus [DATUM/UHRZEIT] aus 3. Verifiziere das Backup ist nicht kompromittiert (Check Backup Integrity Tool) 4. Starte Recovery zu [Recovery-Server-Name] in isolierter Netzwerk-Zone (keine Production-Verbindung) 5. Warte bis Recovery 100% abgeschlossen (ca. X Minuten für dieses System) 6. Boot den Recovery-Server und logge Dich als Local Admin ein (User: xxxx, Pwd: [in Tresor]) 7. Öffne Command Prompt, verifiziere Disk-Space, RAM, Network-Interface funktionieren 8. Laufe Integrity Checks: diskpart /verify, ipconfig /all, systeminfo 9. Wenn alle Checks OK, starte Services: net start servicename 10. Teste Funktionalität: logge Dich als Domain User ein, erstelle eine Test-Datei, ... 11. Wenn alles OK, migriere VM zu Production-Cluster (beschreibe wie) 12. Update DNS/DHCP falls nötig 13. Dokumentiere Abschlusszeit in der Recovery-Log ``` **5. Test-Ver­fah­ren** - Wie tes­ten wir die­sen Run­book regelmäßig? - Bei­spiel: ​“Quar­ter­ly Reco­very Test: Stat­te einen Par­ti­al Reco­very auf Test-Hard­ware durch, ohne Pro­duc­tion zu beeinflussen” - Erfolgs-Kri­te­ri­en: Sys­tem boo­tet, Log­in funk­tio­niert, Ser­vices star­ten, Daten­in­te­gri­tät ok **6. Admin-Cre­den­ti­als (SEPA­RA­TE­LY STORED)** - Pass­words soll­ten NICHT im Run­book selbst stehen - Statt des­sen: ​“Local Admin Cre­den­ti­al: Im Tre­sor unter \[Loca­ti­on\], aktua­li­siert \[Datum\]” - Oder: Hin­ter­le­ger Cre­den­ti­als in einem ver­schlüs­sel­ten Safe, nur für Recovery - Alter­na­ti­ve: Pass­wort-Mana­ger mit Zugriff nur für Inci­dent Commander **7. Trou­ble­shoo­ting-Gui­de** - “Wenn Reco­very abbricht mit Feh­ler XYZ: mache ABC” - “Wenn das Back­up nicht les­bar ist: Ver­su­che Tier 3 WORM-Back­up statt Tier 2” - “Wenn die Reco­very län­ger dau­ert als RTO: nut­ze Bare-Metal-Reco­very für die kri­tischs­ten Daten, Rest später” **8. Post-Reco­very Validation** - Wie veri­fi­zie­ren wir, dass das Sys­tem wirk­lich ok ist? - Bei­spiel für File­ser­ver: ​“Star­te Inte­gri­ty Check auf allen Shares, über­prü­fe dass kei­ne Kor­rup­ti­on vor­han­den ist” - Bei­spiel für Data­ba­se: ​“Füh­re DBCC CHECKDB aus, über­prü­fe Daten­bank­grö­ße, füh­re einen Test-Query aus” ### Die 7 Kern­fra­gen für jedes Run­book [\#](#die-7-kernfragen-f%C3%BCr-jedes-runbook "Die 7 Kernfragen für jedes Runbook") Ein gutes Reco­very-Run­book ant­wor­tet auf die­se 7 Fragen: 1. **Was wird wie­der­her­ge­stellt?** (Sys­tem-Name, Ver­si­on, Betriebssystem) 2. **Woher wird es wie­der­her­ge­stellt?** (Back­up-Loca­ti­on, Zugriff, Credentials) 3. **Wohin wird es wie­der­her­ge­stellt?** (Reco­very-Hard­ware, Netz­werk-Zone, IP-Adressen) 4. **In wel­cher Rei­hen­fol­ge?** (Abhän­gig­keits­dia­gramm) 5. **Wie lan­ge dau­ert das?** (RTO-Schät­zung, tat­säch­lich gemes­sen aus letz­tem Test) 6. **Wie veri­fi­zie­ren wir Erfolg?** (Vali­die­rungs-Schrit­te) 7. **Was tun wir, wenn es schief geht?** (Trou­ble­shoo­ting) Wenn Ihr Run­book die­se 7 Fra­gen nicht klar beant­wor­tet, ist es unvollständig. ### Wer schreibt und pflegt das Run­book [\#](#wer-schreibt-und-pflegt-das-runbook "Wer schreibt und pflegt das Runbook") **Schrei­ben:** Die Team-Mit­glie­der, die das Sys­tem nor­ma­ler­wei­se betreu­en. Sie ken­nen die Fallstricke. **Review:** Der IT-Mana­ger und min­des­tens eine wei­te­re Per­son. Vier-Augen-Prinzip. **Test­ing:** Ein­mal pro Quar­tal soll­te der Run­book als **ech­te Reco­very durch­ge­spielt wer­den**. Nicht nur theo­re­tisch — prak­tisch. Mit ech­tem Back­up, ech­ter Hard­ware (oder VM), ech­ter Restore-Operation. **Pfle­ge:** Nach jeder grö­ße­ren Sys­tem­än­de­rung (Update, Con­fig-Ände­rung, Upgrade). Min­des­tens jähr­lich ein Refresh durch­füh­ren, um sicher­zu­stel­len, dass Pass­words, IP-Adres­sen, etc. noch aktu­ell sind. ### War­um es off­line ver­füg­bar sein muss [\#](#warum-es-offline-verf%C3%BCgbar-sein-muss "Warum es offline verfügbar sein muss") Das ist nicht optio­nal: Der Reco­very-Run­book muss **auf Papier gedruckt im Tre­sor oder Safe ver­füg­bar sein**. War­um? Weil wenn ein Ran­som­wa­re-Angriff Ihr Fir­men­netz­werk lahm­legt, kön­nen Sie nicht auf das Wiki oder Share­Point zugrei­fen. Sie brau­chen ein gedruck­tes Hand­buch, das Ihnen sagt: - Hier ist die IP-Adres­se des Air-Gap-Backup-Systems - Hier ist der Reco­very-Ser­ver wo wir Sys­te­me wiederherstellen - Hier ist die Rei­hen­fol­ge der Wiederherstellung - Hier sind die Admin-Cre­den­ti­als (oder der Hin­weis wo sie sind) Eine Orga­ni­sa­ti­on, die einen Reco­very-Run­book nur digi­tal hat, hat kei­nen Reco­very-Run­book. Sie hat einen gut gemei­nen Text im Wiki, der zu spät ver­füg­bar wird. ### Häu­fi­ge Feh­ler [\#](#h%C3%A4ufige-fehler "Häufige Fehler") **Feh­ler 1: Zu generisch** ​“SAP kann aus Back­up wie­der­her­ge­stellt wer­den” ist nicht genug. Ein guter Run­book hat 20 – 50 detail­lier­te Schritte. **Feh­ler 2: Nicht getestet** Ein Run­book, der nicht regel­mä­ßig (min­des­tens quar­tals­wei­se) durch­ge­spielt wur­de, ist ein Mythos. Er funk­tio­niert erst wenn Sie ihn testen. **Feh­ler 3: Veraltet** Das Sys­tem wur­de upgraded, die IP-Adres­se des Back­up-Sys­tems geän­dert, der Admin-Name geän­dert — aber der Run­book nicht. Der Run­book wird zum Hindernis. **Feh­ler 4: Zu abhän­gig von einer Person** Nur ein Mensch kennt den Run­book. Wenn die­se Per­son im Urlaub ist oder selbst betrof­fen vom Inci­dent, ist der Plan sinnlos. **Feh­ler 5: Zu vie­le Cre­den­ti­als im Dokument** Der Run­book soll­te NICHT alle Pass­wör­ter ent­hal­ten. Das ist ein Sicher­heits­ri­si­ko. Statt des­sen: Ver­weis auf den Safe, wo die Cre­den­ti­als liegen. ### Häu­fi­ge Fra­gen [\#](#h%C3%A4ufige-fragen "Häufige Fragen") **Wie detail­liert muss ein Run­book sein?** Detail­liert genug, dass ein IT-Tech­ni­ker ohne spe­zia­li­sier­tes Wis­sen das Sys­tem wie­der­her­stel­len könn­te. Das heißt: Click-for-Click Anwei­sun­gen wo nötig. **Wie oft müs­sen wir den Run­book testen?** Min­des­tens quar­tals­wei­se (4x pro Jahr). Best Prac­ti­ce: ein­mal pro Quar­tal ein ech­ter Recovery-Test. **Was ist der Unter­schied zwi­schen Reco­very-Run­book und Dis­as­ter Reco­very Plan?** Der DR-Plan ist stra­te­gisch und orga­ni­sa­to­risch (wie reagie­ren wir auf eine Kata­stro­phe?). Der Run­book ist tak­tisch und spe­zi­fisch (wie brin­gen wir Sys­tem X wie­der hoch?). --- ### Disaster Recovery Disaster Recovery bezeichnet die strukturierten Prozesse und technischen Maßnahmen, die sicherstellen, dass IT-Systeme nach einem schwerwiegenden Ausfall — Ransomware-Angriff, Hardwareversagen, Rechenzentrumsausfall — innerhalb definierter Zeitrahmen (RTO) mit maximalem Datenverlust (RPO) wiederhergestellt werden können. [Mehr erfahren →](https://www.fast-lta.de//de/glossar/disaster-recovery) ### WORM WORM (Write Once, Read Many) bezeichnet ein Speicherprinzip, bei dem Daten einmal geschrieben und danach technisch nicht mehr verändert oder gelöscht werden können — bei Hardware-WORM ist diese Unveränderlichkeit eine physikalische Eigenschaft des Speicher-Controllers, unabhängig von Software, Betriebssystem oder Benutzerprivilegien. [Mehr erfahren →](https://www.fast-lta.de//de/glossar/worm) ### WORM WORM (Write Once, Read Many) bezeichnet ein Speicherprinzip, bei dem Daten einmal geschrieben und danach technisch nicht mehr verändert oder gelöscht werden können — bei Hardware-WORM ist diese Unveränderlichkeit eine physikalische Eigenschaft des Speicher-Controllers, unabhängig von Software, Betriebssystem oder Benutzerprivilegien. [Mehr erfahren →](https://www.fast-lta.de//de/glossar/worm)