Recovery-Runbook: Was hineingehört und wer es pflegt

Was in ein Reco­very-Run­book gehört #

Für jedes kri­ti­sche Sys­tem #

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 #

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 #

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 #

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 #

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 #

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?).

---