Viele Teams haben Backups, aber keine belastbare Recovery. Der Unterschied ist praktisch, nicht akademisch. Ein Backup ist ein Artefakt. Recovery ist ein Ablauf mit Zuständigkeiten, Abhängigkeiten, Reihenfolge und Zeitdruck.
Warum Runbooks zuerst kommen sollten
Wenn in einer Störung erst diskutiert wird, welches System zuerst zurückkommt, welches Team wen freischaltet oder wo die letzten Restore-Tests dokumentiert sind, ist das eigentliche Backup nur noch ein Teilproblem. Gute Runbooks reduzieren Unsicherheit, bevor der eigentliche technische Stress beginnt.
- Welche Systeme sind geschäftskritisch und in welcher Reihenfolge werden sie wiederhergestellt?
- Wer entscheidet über Failover, Restore oder bewusste Teilausfälle?
- Wo liegen Zugangsdaten, Offline-Kopien und Kontaktlisten?
- Wie wird dokumentiert, was schon wiederhergestellt wurde und was noch fehlt?
RPO und RTO nur dann sinnvoll, wenn geübt wird
RPO/RTO-Werte helfen nur, wenn sie in echten Übungen überprüft werden. Für viele KMU reicht schon ein strukturierter monatlicher Restore-Test für ein repräsentatives System, solange er dokumentiert, wiederholbar und realistisch ist.
Typische Lücken
- Backups laufen, aber niemand prüft die Lesbarkeit der Wiederherstellungspfade.
- Service-Abhängigkeiten sind nicht dokumentiert.
- Einzelsysteme werden getestet, komplette Wiederanläufe aber nie.
- Zuständigkeiten hängen an einzelnen Personen statt an Rollen.
5-Minuten-Checkliste
- Für die Top-5-Systeme eine Reihenfolge der Wiederherstellung definieren.
- Runbook für Restore inklusive Rollen, Kontakten und Freigaben dokumentieren.
- Monatlich mindestens einen Restore-Test terminieren.
- RPO/RTO gegen echte Übungswerte spiegeln.
- Nach jeder Übung drei konkrete Verbesserungen nachziehen.