Ein ausgefallener Server, eine beschädigte Datenbank und ein nicht erreichbares Rechenzentrum brauchen unterschiedliche Antworten. Hochverfügbarkeit fängt definierte Komponentenausfälle auf. Backup liefert einen früheren Datenstand. Disaster Recovery organisiert den Wiederanlauf. Entscheidend ist, welche Arbeit weiterlaufen muss und wann Ihre Anwendungen wieder nutzbar sein sollen.
Hochverfügbarkeit
Betrieb bei definierten Ausfällen fortsetzen
Backup
Daten aus einem gesicherten Stand herstellen
Disaster Recovery
Dienste in abgestimmter Reihenfolge wieder anlaufen lassen
Zwei Ziele. Zwei unterschiedliche Fragen.
Wie viel an Daten darf fehlen?
Letzter nutzbarer Datenstand bis zum AusfallWann muss die Anwendung wieder nutzbar sein?
Ausfall bis zur nutzbaren AnwendungBeispielwerte, keine Empfehlung oder Leistungszusage. Beide Ziele werden mit dem Fachbereich vereinbart. Die Darstellung ist nicht maßstabsgetreu.
Welchen Ausfall müssen Sie auffangen?
| Situation | Mögliche Antwort | Entscheidende Voraussetzung |
|---|---|---|
| Ein Host fällt aus | VMs auf verbleibenden Hosts neu starten | HA korrekt eingerichtet, Daten erreichbar und ausreichend Reserve vorhanden. |
| Eine Datenbank ist beschädigt | Geeigneten Sicherungsstand wiederherstellen | Datenstand und Anwendungskonsistenz sind geprüft. |
| Das Storage-System fällt aus | Unabhängige Redundanz oder Wiederherstellung | Ein zweiter Controller allein schützt nicht vor jedem Fehler des Gesamtsystems. |
| Ein Standort ist nicht nutzbar | Vorbereiteten Ersatzbetrieb aufnehmen | Kapazität, Zugänge, Netzwerk und Basisdienste stehen bereit. |
| Administrative Zugänge sind kompromittiert | Vorfall eingrenzen und kontrolliert wiederherstellen | Sicherungen und Notfallzugänge sind geschützt. Bereinigung und Freigabe erfolgen mit den Zuständigen für den Sicherheitsvorfall. |
Ausfallzeit und Datenverlust getrennt festlegen
Ein Beispiel: Die Auftragsbearbeitung soll nach vier Stunden wieder nutzbar sein. Höchstens 30 Minuten an Daten dürfen fehlen. Die vier Stunden sind das Wiederanlaufziel (RTO), die 30 Minuten das Datenverlustziel (RPO). Diese Beispielwerte sind keine Empfehlung für Ihre Umgebung. Vereinbaren Sie die Ziele mit dem Fachbereich und prüfen Sie, ob Ihre Technik sie erreicht. Zur Zeit zählen auch Basisdienste, Anwendungsstart und Funktionsprüfung. Replikation kann beschädigte Daten weitergeben und ersetzt deshalb kein Backup.
Die Abhängigkeiten des Wiederanlaufs berücksichtigen
Eine gestartete VM ist noch keine wiederhergestellte Anwendung. Identitätsdienste, DNS, Netzwerk, Datenbanken und externe Verbindungen müssen in der richtigen Reihenfolge verfügbar sein. Für einen Standortausfall können andere Maßnahmen nötig sein als für einen Sicherheitsvorfall.
- Sicherungen vom Ausfall- und Angriffsszenario ausreichend trennen.
- Benötigte Kapazität, Zugänge und Schlüssel für den Wiederanlauf verfügbar halten.
- Verantwortung und Freigabe auch bei Ausfall der üblichen Kommunikationswege regeln.
Tests am tatsächlichen Ergebnis messen
Prüfen Sie nicht nur, ob eine Sicherung gelesen werden kann. Lassen Sie den Fachbereich eine relevante Funktion der wiederhergestellten Anwendung prüfen. Dokumentieren Sie Dauer, verwendeten Datenstand, Abweichungen und offene Maßnahmen. Ein erfolgreicher Einzeltest belegt nur das getestete Szenario, nicht die gesamte Notfallfähigkeit.
Diese Fragen sollten geklärt sein
- Anwendung sowie fachliche und technische Verantwortliche festhalten.
- Benötigte Basisdienste, Schnittstellen und Wiederherstellungszugänge erfassen.
- Wiederanlaufzeit und tolerierbaren Datenverlust vereinbaren.
- Datum, Szenario, gemessene Dauer und Datenstand des letzten Tests dokumentieren.
- Funktion durch den Fachbereich prüfen lassen und offene Maßnahmen zuweisen.
MCE Bank
Bei der MCE Bank ergänzen Offsite-Backup und regelmäßig protokollierte Wiederherstellungstests die redundante Infrastruktur. Im Projektbericht sind Aufbau und laufender Betrieb beschrieben.
Projekt ansehen