Einblicke aus der Praxis

Notfallbetrieb und Disaster Recovery: Welches Schutzniveau lohnt sich?

Backup, lokale Hochverfügbarkeit oder zweiter Standort? Ein fiktives ERP zeigt Fehlerdomänen, RPO/RTO-Grenzen und offene Kosten über drei und fünf Jahre.

Infrastruktur
DAXS-Dackel und Wortmarke über drei Schutzstufen für ein fiktives ERP: Backup und Restore holen einen Datenstand zurück, lokale Hochverfügbarkeit federt Hostfehler ab und ein zweiter Standort plant den Standortausfall; alle Stufen behalten ein getrenntes Backup

Das passende Schutzniveau hängt vom Ausfall ab, den ein Unternehmen überstehen muss. Ein Backup beantwortet die Frage nach einem wiederherstellbaren Datenstand. Lokale Hochverfügbarkeit kann einen Hostfehler abfedern. Ein zweiter Standort erweitert die Fehlerdomäne, verlangt aber eigene Kapazität, Netze und geübte Umschaltung. Keiner dieser Wege ersetzt die fachliche Abnahme der Anwendung.

Die Wiederherstellungsprüfung und der Unterschied zwischen Proxmox-HA und Backup sind bereits eigene Themen. Hier treffen wir eine andere Entscheidung: Welche Kombination aus Backup, lokalem Ersatz und räumlich getrenntem Notbetrieb passt zu einem konkreten Dienst und einer bestimmten Fehlerdomäne? Die öffentliche Plattformübersicht ersetzt diese Anwendungssicht ebenfalls nicht.

Erst den Geschäftsfall und zwei Zeitziele festlegen

Unser ausdrücklich fiktives Beispiel ist ein ERP mit Anwendungs-VM, Datenbank und Rechnungsdateien. Der Fachbereich will bei einem Ausfall des ganzen Standorts innerhalb von vier Stunden wieder Aufträge bearbeiten können und höchstens 15 Minuten konsistenter Geschäftsdaten verlieren. Das sind Ziele für RTO und RPO, keine DAXS-Zusage und kein gemessener Wert. Für einen einzelnen Hostfehler wäre ein kürzeres Ziel denkbar; ein versehentlich gelöschter Vorgang verlangt dagegen einen älteren, unveränderten Wiederherstellungspunkt.

Die Business-Impact-Analyse muss deshalb Hostausfall, Standortausfall und beschädigte oder gelöschte Daten getrennt bewerten. Ein Dienst gilt erst als zurück, wenn Anmeldung, Datenbankaktion und zugehöriger Dateianhang im Notbetrieb funktionieren. Strom, Standortnetz, DNS, Identität, Schlüssel und externe Schnittstellen gehören zur Abhängigkeitskette. Fehlt einer dieser Teile, ist ein gestarteter Ersatzserver noch kein nutzbarer Betrieb.

Drei Schutzstufen mit unterschiedlichen Grenzen

Schutz für dasselbe fiktive ERP, jeweils mit getrenntem Backup
Schutzstufe Was sie leisten kann Was offen bleibt
A · Backup und Restore Getrennte Sicherungen erlauben die Rückkehr zu einem geprüften Datenstand; nach Bereitstellung eines Zielsystems wird die Anwendung wiederhergestellt. Ersatzkapazität, Restore-Dauer und fachliche Konsistenz bestimmen den RTO. Bei Standortverlust ohne bereitstehenden Zielort gibt es keine belastbare Vier-Stunden-Zusage.
B · Lokale Redundanz plus Backup Mehrere Hosts mit passend ausgelegtem Storage, Quorum und Netz können eine VM nach einem Hostfehler auf anderen Ressourcen starten. Gemeinsamer Strom, Brandabschnitt oder Standortzugang bleiben eine Fehlerdomäne. Gelöschte oder beschädigte Daten können sich replizieren; getrenntes Backup bleibt nötig.
C · Zweiter Standort plus Backup Räumlich getrennte, vorbereitete Notkapazität mit replizierten Anwendungsdaten kann den Standortverlust abdecken, sofern Umschaltung und Geschäftsfall geübt sind. Replikationsverzug, gemeinsame Identitätsdienste, Leitungen, Schlüssel und ein fehlerhafter Failover können das 15-Minuten-/Vier-Stunden-Ziel verfehlen. Auch hier braucht es getrennte Backups.

Lokale HA ist damit eine mögliche Antwort auf einen Hostfehler, kein automatisch funktionierendes Disaster Recovery für den ganzen Standort. Microsoft trennt Redundanz und Replikation ausdrücklich von Backup: Ein replizierter Fehler oder eine Löschung bleibt ein Fehler. Die AWS-Architekturleitlinie beschreibt Backup/Restore, Pilot Light, Warm Standby und aktive Mehrstandortmodelle als Strategien mit steigendem Aufwand. Diese Cloud-Muster sind eine Entscheidungslogik, keine pauschalen RPO-/RTO-Werte für das hier angenommene eigene ERP.

Gleichwertiger Umfang: eine offene Drei- und Fünfjahresrechnung

Für jede Stufe bleibt derselbe produktive ERP-Dienst und dasselbe getrennte Backup-Grundprogramm im Vergleich. Die bereits vorhandene produktive Plattform ist deshalb in keiner Variante eingerechnet. Einmalig fallen für Backup-Runbook und Testgrundlage 24 Personenstunden an; jährlich 3.600 € beispielhafte externe Backup-/Speicherleistung, 12 × 4 Personenstunden Betrieb und zwei Restore-Übungen mit je 16 Personenstunden. Der frei angenommene Vollkostensatz beträgt 80 € je Personenstunde: einmalig 1.920 €, jährlich 3.600 + (48 + 32) × 80 = 10.000 €. Das sind keine Anbieterpreise.

Stufe B ergänzt einmalig 60 Personenstunden für Host-/Storage-/Netzkonzept und Abnahme sowie jährlich 7.800 € beispielhafte zusätzliche lokale Kapazität inklusive Energie und Support, 12 × 4 weitere Betriebsstunden und zwei HA-Übungen mit je acht zusätzlichen Personenstunden. Stufe C ergänzt stattdessen einmalig 96 Personenstunden für Standort-, Daten- und Umschaltkonzept sowie jährlich 18.000 € vorbereitete Notkapazität und Netz, 3.600 € Datenübertragung, 12 × 8 zusätzliche Betriebsstunden und zwei Standortübungen mit je 24 zusätzlichen Personenstunden. Alle Übungsstunden sind Team-Summen; die gemeinsame Backup-Basis wird je Variante nur einmal gezählt.

Gleicher ERP- und Backup-Umfang, unterschiedliche zusätzliche Schutzdomäne
Stufe Einmalig Jährlich 3 Jahre 5 Jahre
A · Backup/Restore 24 × 80 = 1.920 € 10.000 € Basis 31.920 € 51.920 €
B · lokale Redundanz 1.920 + 60 × 80 = 6.720 € 10.000 + 7.800 + 3.840 + 1.280 = 22.920 € 75.480 € 121.320 €
C · zweiter Standort 1.920 + 96 × 80 = 9.600 € 10.000 + 18.000 + 3.600 + 7.680 + 3.840 = 43.120 € 138.960 € 225.200 €

Sensitivität: Kostet die vorbereitete Zweitstandortkapazität 500 € pro Monat mehr als angenommen, steigt Stufe C um 6.000 € im Jahr: auf 156.960 € über drei beziehungsweise 255.200 € über fünf Jahre. Ersatzteile, Steuern, echte Leitungs- und Standortangebote, Lizenzrechte, Betrieb außerhalb der angenommenen Stunden und Kosten eines tatsächlichen Ausfalls müssen vor einer Beschaffung ergänzt werden. Keine Variante verspricht eine Einsparung oder einen garantierten Wiederanlauf.

Die Entscheidung im Test treffen

Für das angenommene Vier-Stunden-/15-Minuten-Ziel beim Standortausfall fallen A und B als alleinige Lösung aus, solange kein anderer nutzbarer Ort mit Daten, Identität und Netzzugang bereitsteht. C ist nur ein Kandidat: Das Team muss Replikationsstand, Datenbank-Datei-Konsistenz, Zugriff, Umschaltentscheidung, Kapazität unter Last und Rückweg im echten Testfenster messen. Wenn der Fachbereich einen längeren Notbetrieb mit manueller Auftragsannahme akzeptiert, kann ein günstigerer Weg ausreichend sein. Das muss ausdrücklich beschlossen, protokolliert und geübt werden.

DAXS kann den Dienst und seine Abhängigkeiten aufnehmen, einen kleinsten fachlich nutzbaren Notbetrieb definieren und die drei Varianten mit echten Angeboten und Restore-/Failover-Ergebnissen vergleichbar machen. Kontakt zu DAXS.

Quellen: Microsoft Learn: Redundanz, Replikation und Backup · AWS Well-Architected: Disaster-Recovery-Strategien · Proxmox VE: Funktionen für HA und Backup.