Backup ist eine technische Maßnahme – Recovery ist ein Betriebsprozess. Wer im Ernstfall Systeme wiederherstellen muss, braucht mehr als grüne Häkchen in einer Backup-Konsole.
Daten und Sicherungen voneinander trennen
Ein Backup, das mit denselben Administratorzugängen erreichbar ist wie das Produktivsystem, kann bei einem Sicherheitsvorfall ebenfalls betroffen sein. Getrennte Sicherungsziele und Offsite-Kopien reduzieren dieses Risiko.
- mehrere Sicherungskopien
- Offsite oder getrenntes Ziel
- Zugriffe auf Backup-Systeme einschränken
- immutable bzw. manipulationsgeschützte Konzepte prüfen
RPO und RTO in verständliche Ziele übersetzen
Wie viele Daten dürfen im Ernstfall fehlen und wie schnell muss ein System wieder laufen? Diese Fragen sollten pro Dienst beantwortet werden – nicht pauschal für „die IT“.
- kritische Systeme priorisieren
- zulässigen Datenverlust definieren
- Wiederanlaufzeit festlegen
- Abhängigkeiten im Restore berücksichtigen
Restore-Tests gehören zum normalen Betrieb
Regelmäßige Tests zeigen, ob Daten tatsächlich lesbar sind, Zugangsdaten verfügbar sind und die Wiederherstellungsanleitung funktioniert.
- Datei-Restore testen
- VM/System-Restore testen
- Anwendungsstart prüfen
- Ergebnis dokumentieren
Recovery darf nicht an einer Person hängen
Wenn nur eine Person weiß, wo Backups liegen oder wie ein Restore funktioniert, bleibt ein organisatorischer Single Point of Failure. Dokumentation und Vertretung gehören deshalb zur Recovery-Strategie.
- Zugänge dokumentieren
- Recovery-Schritte festhalten
- Vertretung definieren
- Notfallkontakt und Eskalation festlegen