Hochverfügbarkeit vs. Disaster Recovery: Der Unterschied

Warum die Begriffe so häufig vermischt werden

Backup, Hochverfügbarkeit und Disaster Recovery verfolgen ein gemeinsames Oberziel: Informationen und Dienste sollen verfügbar bleiben oder nach einer Störung wieder verfügbar werden. Weil sie dasselbe Oberziel haben, werden sie in Angeboten, Gesprächen und Ausschreibungen häufig synonym verwendet. Fachlich handelt es sich jedoch um drei unterschiedliche Konzepte, die auf unterschiedliche Ursachen von Ausfällen antworten und unterschiedliche Kosten, Abhängigkeiten und Grenzen haben.

Wer die Konzepte nicht trennt, trifft leicht falsche Entscheidungen: Ein Unternehmen, das einen redundanten Server-Cluster betreibt, hält sich womöglich für abgesichert, obwohl keine einzige unabhängige Kopie seiner Daten existiert. Umgekehrt verfügt ein Betrieb mit sorgfältigen Backups über keine Antwort auf die Frage, wie die Kundenbetreuung am Montagmorgen weiterläuft, wenn der Serverraum nach einem Wasserschaden nicht mehr nutzbar ist. Dieser Beitrag grenzt die drei Konzepte voneinander ab, ordnet sie über gemeinsame Kennzahlen ein und zeigt, wie sie sich sinnvoll kombinieren lassen.

Backup: frühere Stände wiederherstellen

Ein Backup ist eine gesonderte Kopie von Daten oder Systemen, die zu einem bestimmten Zeitpunkt erstellt wurde und unabhängig vom Original aufbewahrt wird. Sein Kernnutzen liegt in der zeitlichen Dimension: Ein Backup erlaubt es, auf einen früheren Zustand zurückzugehen. Damit beantwortet es Ereignisse, bei denen der aktuelle Zustand selbst das Problem ist, etwa versehentliche Löschung, fehlerhafte Programmupdates, Datenbeschädigung, Hardwaredefekte oder Verschlüsselung durch Schadsoftware.

Die Stärke des Backups ist zugleich seine Schwäche: Weil erst wiederhergestellt werden muss, vergeht Zeit, die von Datenmenge, Bandbreite, Zielumgebung und Vorbereitung abhängt. Ein Backup verkürzt Ausfallzeiten also nicht von sich aus, es macht sie überhaupt erst endlich. Grundlagen zur Auslegung finden Sie im Beitrag zur 3-2-1-Regel.

Hochverfügbarkeit: Ausfälle vermeiden statt beheben

Hochverfügbarkeit (englisch High Availability) bezeichnet Architekturen, die den Ausfall einzelner Komponenten ohne oder mit nur sehr kurzer Unterbrechung des Dienstes verkraften. Das Prinzip ist Redundanz: Kritische Bestandteile, etwa Server, Netzteile, Speichersysteme oder Netzwerkverbindungen, sind mehrfach vorhanden, damit keine einzelne Komponente zum Single Point of Failure wird. Fällt ein Teil aus, übernimmt ein anderer, entweder automatisch durch eine Clustersoftware oder manuell auf Anweisung.

Man unterscheidet grob zwischen aktiv-aktiven Konstruktionen, bei denen mehrere Instanzen gleichzeitig Last tragen, und aktiv-passiven Konstruktionen, bei denen eine Reserve bereitsteht und erst im Störungsfall aktiviert wird. Je enger die tolerierte Unterbrechung, desto höher sind Komplexität und Kosten: Die Systeme müssen synchron gehalten, überwacht und regelmäßig auf ihr Umschaltverhalten geprüft werden. Hochverfügbarkeit ist deshalb eine bewusste Investition für Systeme, bei denen jede Minute Stillstand spürbare Folgen hat, und kein Standard für die gesamte IT.

Wie Verfügbarkeit gemessen und häufig missverstanden wird

Verfügbarkeit wird üblicherweise als Anteil der Zeit angegeben, in der ein Dienst nutzbar ist. Solche Prozentwerte klingen präzise, hängen aber stark von der Definition ab: Gemessen wird manchmal nur der Betrieb der Technik, manchmal die tatsächliche Nutzbarkeit für Anwenderinnen und Anwender; geplante Wartungsfenster werden mal eingerechnet, mal ausgenommen. Zwei Angaben mit derselben Zahl können daher Unterschiedliches bedeuten.

Für Ihre Entscheidung ist eine andere Sicht hilfreicher: Welche Unterbrechung kann ein Prozess verkraften, und welche Ereignisse führen realistisch zu Unterbrechungen? Verfügbarkeitsangaben von Anbietern sind ein Ausgangspunkt, aber kein Ersatz für die eigene Betrachtung der gesamten Kette aus Strom, Netzwerk, Server, Speicher, Software und Bedienung. Die schwächste Stelle bestimmt das Ergebnis.

Warum Redundanz kein Backup ersetzt

Redundante Systeme schützen vor dem Ausfall von Komponenten, aber nicht vor Fehlern im Inhalt. Wird eine Datei versehentlich gelöscht, eine Datenbanktabelle fehlerhaft überschrieben oder ein System durch Ransomware verschlüsselt, so wird dieser Zustand bei synchroner Spiegelung unmittelbar auf die Reserve übertragen. Beide Systeme enthalten dann denselben fehlerhaften Stand. Das ist kein Konstruktionsfehler, sondern der Zweck der Replikation: Sie soll den aktuellen Zustand möglichst schnell und vollständig duplizieren.

Eine ähnliche Unterscheidung trifft der Beitrag Backup, Snapshot, Replikation. Merken Sie sich die Faustregel: Redundanz beantwortet die Frage „Was passiert, wenn ein Gerät kaputtgeht?“, ein Backup die Frage „Was passiert, wenn der Inhalt falsch oder weg ist?“. Beide Fragen sind berechtigt, und keine ersetzt die andere.

Disaster Recovery: ein Prozess, kein Produkt

Disaster Recovery, auf Deutsch auch Notfallwiederherstellung, bezeichnet die Gesamtheit der organisatorischen und technischen Maßnahmen, mit denen nach einem umfangreichen Schadensereignis der Betrieb wiederaufgenommen wird. Typische Ereignisse sind der Verlust eines Standorts durch Brand, Wasser oder Stromausfall, der gleichzeitige Ausfall vieler Systeme oder ein großflächiger Cyberangriff. Entscheidend ist, dass Disaster Recovery nicht mit einer einzelnen Technik identisch ist. Ein Backup ist Bestandteil, aber nicht der ganze Prozess.

Ein belastbares Konzept umfasst in der Regel folgende Elemente: eine Analyse, welche Geschäftsprozesse und Systeme in welcher Reihenfolge wieder laufen müssen (häufig als Business-Impact-Analyse bezeichnet), eine Zielumgebung, in der die Systeme betrieben werden können, einen dokumentierten Wiederanlaufplan mit Zuständigkeiten, Kommunikationswegen und Abhängigkeiten sowie regelmäßige Übungen. Rahmenwerke wie ISO 22301 zum Business-Continuity-Management, der BSI-Standard 200-4 und der NIST-Leitfaden SP 800-34 zur Notfallplanung beschreiben dieses Vorgehen ausführlich. Die Technik ist dort ein Baustein unter mehreren, und Fachleute betonen regelmäßig, dass die organisatorischen Teile über Erfolg oder Misserfolg im Ernstfall entscheiden.

Hochverfügbarkeit und Disaster Recovery im Direktvergleich

Die Unterschiede lassen sich in vier Dimensionen fassen:

• Ziel: Hochverfügbarkeit hält Unterbrechungen so kurz wie möglich, im Idealfall unbemerkt. Disaster Recovery stellt nach einem großen Ausfall die Arbeitsfähigkeit wieder her, wobei eine spürbare Unterbrechung eingeplant ist.
• Prinzip: Bei Hochverfügbarkeit übernimmt eine bereits laufende Reserve. Bei Disaster Recovery werden Systeme nach einem Plan an anderer Stelle neu in Betrieb genommen, zum Beispiel aus Backups.
• Typischer Auslöser: Hochverfügbarkeit greift beim Ausfall einzelner Komponenten. Disaster Recovery greift, wenn ein Standort oder viele Systeme gleichzeitig betroffen sind.
• Schutz vor Löschung und Fehlern: Hochverfügbarkeit bietet ihn nicht, denn Fehler werden mitübernommen. Bei Disaster Recovery hängt er davon ab, aus welchen Sicherungsständen der Wiederanlauf erfolgt.
• Aufwand: Hochverfügbarkeit bedeutet dauerhaft laufende Doppelstrukturen. Disaster Recovery verursacht je nach Konzept vor allem Planungs-, Test- und Bereitschaftsaufwand, laufende Kosten entstehen mitunter erst im Einsatz.

RPO und RTO als gemeinsamer Maßstab

Um die drei Konzepte gegeneinander abzuwägen, benötigen Sie quantitative Anforderungen. Dafür haben sich zwei Kennzahlen etabliert: das Recovery Point Objective (RPO), der tolerierte Datenverlust gemessen in Zeit, und das Recovery Time Objective (RTO), die angestrebte Zeit bis zur Wiederinbetriebnahme. Beide werden pro System oder Prozess festgelegt, nicht pauschal für das gesamte Unternehmen. Eine ausführliche Herleitung bietet der Beitrag RPO und RTO einfach erklärt.

Die Kennzahlen machen sichtbar, welches Konzept zu welcher Anforderung passt. Ein Backup bestimmt das RPO über sein Sicherungsintervall und das RTO über die Dauer der Wiederherstellung. Hochverfügbarkeit senkt das RTO im Falle eines Komponentenausfalls auf nahezu null, hat aber für das Szenario „Daten falsch oder gelöscht“ keinen Einfluss auf das RPO. Disaster Recovery liegt typischerweise dazwischen: Das RTO ist länger als bei Hochverfügbarkeit, dafür deckt das Konzept das Szenario des Standortverlusts ab. Wichtig bleibt: Beide Werte sind Ziele, die Sie durch Tests belegen müssen, und keine Zusagen, die sich aus einem Werkzeug von selbst ergeben.

Ein konstruiertes Beispiel

Zur Veranschaulichung ein Gedankenbeispiel, das keinen realen Fall beschreibt. Ein Unternehmen betreibt eine Warenwirtschaft auf einem Server, eine Dateiablage und ein Testsystem. Bei der Analyse stellt sich heraus, dass ein Ausfall der Warenwirtschaft binnen weniger Stunden den Versand lahmlegt, während die Dateiablage einen Tag und das Testsystem mehrere Tage entbehrlich sind.

Daraus ergibt sich eine abgestufte Lösung: Alle drei Systeme erhalten ein Backup mit geprüfter Wiederherstellung. Für die Warenwirtschaft prüft das Unternehmen zusätzlich, ob ein redundanter Betrieb wirtschaftlich vertretbar ist, und plant außerdem einen Wiederanlauf an einem anderen Ort ein, falls das Gebäude nicht nutzbar ist. Für Dateiablage und Testsystem genügt der Wiederanlauf aus dem Backup nach der Warenwirtschaft. Der Gewinn dieses Vorgehens liegt in der bewussten Entscheidung pro System, statt in dem Versuch, alles gleich stark abzusichern.

Typische Fehlannahmen

• „Wir haben einen Cluster, also brauchen wir kein Backup.“ Ein Cluster repliziert auch Fehler und Verschlüsselung.
• „Wir haben ein Backup, also haben wir Disaster Recovery.“ Ohne Zielumgebung, Wiederanlaufplan und Test bleibt offen, ob und wie schnell der Betrieb wieder läuft.
• „Disaster Recovery betrifft nur Katastrophen.“ Auch ein Cyberangriff oder ein defektes Speichersystem kann viele Systeme gleichzeitig treffen und einen strukturierten Wiederanlauf erfordern.
• „Hochverfügbarkeit bedeutet, dass nie etwas ausfällt.“ Sie senkt die Wahrscheinlichkeit und Dauer von Unterbrechungen durch Komponentenausfälle, kann aber Fehlbedienung, Softwarefehler und Angriffe nicht ausschließen.
• „Ein Plan, der nie geübt wurde, funktioniert.“ Abhängigkeiten, veraltete Zugangsdaten und fehlende Berechtigungen zeigen sich erfahrungsgemäß erst im Test.

Welche Kombination passt zu Ihrem Unternehmen?

Eine praktikable Vorgehensweise besteht aus drei Schritten. Erstens erfassen Sie Ihre Systeme und bewerten pro System, was ein Ausfall von einer Stunde, einem Tag und einer Woche bedeutet. Zweitens legen Sie auf dieser Grundlage für jedes System RPO und RTO fest. Drittens wählen Sie die Maßnahme, die diese Ziele erreicht, ohne mehr Aufwand zu erzeugen als nötig:

• Für nahezu jedes Unternehmen: ein Backup mit geprüfter Wiederherstellung, getrennt von den Produktivsystemen aufbewahrt.
• Für Systeme mit sehr kurzer tragbarer Ausfallzeit: zusätzlich eine redundante Auslegung, sofern Kosten und Betriebsaufwand vertretbar sind.
• Für kritische Systeme mit Standortrisiko: zusätzlich ein Disaster-Recovery-Konzept mit Zielumgebung, Wiederanlaufplan und regelmäßigem Test.

Umsetzung mit der Plattform

Mit der Plattform sichern Sie physische Server, virtuelle Maschinen, Arbeitsplätze und Cloud-Workloads nach einheitlichen Plänen, siehe Backup aller Workloads. Bei einem Ausfall können Sie wichtige Systeme aus Ihren Backups in der Cloud starten, die Reihenfolge legen Sie in Wiederanlaufplänen fest, ein Test-Failover läuft in einer isolierten Umgebung. Abgerechnet wird nur, was im Test oder Ernstfall tatsächlich läuft, siehe Cloud-Failover und Failback.

Diese Funktion ist keine Hochverfügbarkeitslösung: Die Systeme müssen erst aus dem Backup gestartet werden, und feste Wiederanlaufzeiten sind nicht zugesagt. Der Ablauf im Einzelnen wird im Beitrag Failover und Failback einfach erklärt beschrieben. Netzwerk, Zugriff und Organisation bereiten Sie vor, auf Wunsch unterstützen wir Sie gegen Vergütung.

Grenzen und offene Punkte

Kein Konzept deckt alle Szenarien vollständig ab. Ob eine Kombination ausreicht, hängt von Ihren Anforderungen, den Abhängigkeiten zwischen Systemen und der Qualität der Umsetzung ab. Rechtliche und vertragliche Anforderungen, etwa aus Kundenverträgen, Versicherungen oder Branchenvorgaben, müssen Sie im Einzelfall prüfen. Die genannten Rahmenwerke geben Orientierung, ersetzen aber keine Bewertung Ihrer konkreten Situation. Wer die Anforderungen nicht selbst bestimmen kann, sollte vor der Auswahl einer Technik zunächst die Business-Impact-Analyse durchführen oder sich dabei unterstützen lassen.