Backup, Replikation und Recovery

Vier Wörter, vier verschiedene Zusagen

Snapshot, Backup, Replikation und Hochverfügbarkeit werden im Alltag gern zu einem einzigen Sicherheitsgefühl zusammengezogen. Technisch beantworten sie verschiedene Fragen. Ein Snapshot hält einen kurzfristigen Rücksprung innerhalb derselben Speicherbeziehung bereit. Ein Backup erzeugt eine gesondert verwaltete Kopie mit Aufbewahrung. Replikation überträgt Änderungen auf ein zweites Ziel und kann dabei auch fehlerhafte Änderungen schnell kopieren. HA startet eine Workload nach einem Infrastrukturfehler neu, bewahrt aber nicht automatisch einen früheren Datenstand. Wer diese Zusagen vermischt, entdeckt erst im Incident, dass die vorhandene Technik den eingetretenen Fehler gar nicht abdeckt.

Recovery-Vertrag — Eine benannte Zusage aus wiederherzustellendem Dienstumfang, maximalem Datenverlust, maximaler Wiederanlaufzeit, zulässigem Recoverypunkt, verantwortlichen Rollen und einer Abnahme, die den Dienst wieder freigibt.

Der Vertrag beginnt deshalb mit einem Bedrohungsmodell. Ein Hostdefekt verlangt eine andere Reaktion als ein versehentlich gelöschter Datensatz, eine korrupte Datenbank oder ein kompromittiertes Administratorkonto. Beim Hostdefekt darf der jüngste replizierte Stand wertvoll sein; bei logischer Korruption bewahrt gerade die zeitliche Historie den brauchbaren Punkt. Beim Standortausfall zählen Entfernung, Strom und Netz. Bei Ransomware zählen getrennte Identitäten, unveränderbare Aufbewahrung und die Möglichkeit, ohne Kontakt zur betroffenen Produktionsumgebung zu prüfen. Jede Schutzmaßnahme wird gegen diese Fälle abgehakt. Bleibt ein Fall ungeschützt, ist das kein technisches Detail, sondern eine offene Abweichung vom Dienstvertrag mit benanntem Owner und Termin. Dieses Vorgehen verhindert die verbreitete Aussage, ein Produkt decke „Disaster Recovery“ pauschal ab. Produkte stellen Mechanismen bereit; der Betreiber kombiniert sie zu einer Zusage für konkrete Ausfälle. Dazu gehört auch der Preis: mehr Kopien erhöhen Kosten, engere Intervalle erhöhen Last und komplexere Isolation verlangsamt spontane Zugriffe. Diese Nachteile werden bewusst akzeptiert oder führen zu einem schwächeren, ehrlich dokumentierten Ziel.

RPO und RTO sind fachliche Grenzwerte

Das Recovery Point Objective beschreibt den maximal akzeptierten Datenverlust als Zeitabstand zwischen dem gewählten Wiederherstellungspunkt und dem Störungszeitpunkt. Das Recovery Time Objective beschreibt, wie lange die Wiederherstellung des vereinbarten Dienstumfangs dauern darf. Beide Werte kommen aus der Dienstwirkung, nicht aus einer Produktfunktion. Eine stündliche asynchrone Replikation belegt kein RPO von fünf Minuten. Ein Restore der virtuellen Disks in zwanzig Minuten belegt kein RTO von dreißig Minuten, wenn DNS, Identität, Schlüssel, Datenbankprüfung und fachliche Freigabe weitere zwei Stunden benötigen.

Ziel

Was gemessen wird

RPO

Alter des fachlich akzeptierten Datenstands beim Recovery

RTO

Zeit von Aktivierung des Plans bis zur abgenommenen Dienstfähigkeit

Aufbewahrung

Wie weit und wie fein Recoverypunkte zurückreichen

Recovery Scope

Welche VMs, Daten, Identitäten und Abhängigkeiten gemeinsam zurückkehren

Ein Snapshot bleibt an seiner Basis hängen

Bei vSphere schreibt ein VM-Snapshot neue Änderungen in Delta-Dateien; die Basisdisk bleibt Teil der Kette. Broadcom warnt deshalb ausdrücklich davor, Snapshots als Backups zu verwenden. Gehen Basisdisk oder Datastore verloren, reicht die Delta-Datei nicht zur Wiederherstellung. Lange Ketten erhöhen außerdem Speicherbedarf, Laufzeitrisiko und Aufwand beim Konsolidieren. Ein Snapshot ist sinnvoll als kurzer, beobachteter Rückfallpunkt vor einem begrenzten Change. Er braucht Eigentümer, Ablaufzeit und ausreichend freien Datastore-Platz. Er ist keine unabhängige Kopie und keine Aufbewahrungsstrategie.

Konsistenz gehört zur Anwendung, nicht zum Dateiformat

Eine VM-Kopie kann crash-konsistent sein: Sie entspricht ungefähr dem Zustand nach einem abrupten Stromverlust. Journaling-Dateisysteme können diesen Zustand oft reparieren, doch daraus folgt keine vollständige Anwendungskonsistenz. Datenbanken, Verzeichnisdienste und verteilte Anwendungen besitzen eigene Schreibreihenfolgen, Transaktionslogs und Quorumregeln. Für sie muss der Schutzpfad dokumentieren, ob Gastintegration, anwendungsspezifische Sicherung oder koordinierte Stilllegung eingesetzt wird. Die Hypervisoranzeige „completed“ kann nur den Mechanismus bestätigen, nicht die fachliche Konsistenz aller Daten.

• Crash-konsistent: virtuelle Blöcke bilden einen absturzähnlichen Zeitpunkt ab.
• Dateisystemkonsistent: Dateisystemmetadaten sind in einem erwarteten Zustand; die Anwendung kann trotzdem Nacharbeit brauchen.
• Anwendungskonsistent: der anwendungseigene Mechanismus hat einen definierten Recoverypunkt hergestellt.
• Dienstkonsistent: zusammengehörige Systeme und Abhängigkeiten lassen sich als nutzbarer Dienst abnehmen.

Die passende Stufe hängt vom Dienst ab. Eine stateless Web-VM kann aus einer Vorlage neu entstehen, während ihre Datenbank und Schlüssel einen strengeren Vertrag brauchen. Der Hypervisor schützt den VM-Zustand; der Service Owner entscheidet, welcher Datenstand fachlich akzeptabel ist.

Replikation kopiert Verfügbarkeit und Fehler

Hyper-V Replica hält eine asynchrone Kopie der virtuellen Disks auf einem zweiten Host oder Cluster. Microsoft trennt das ausdrücklich vom Failover Cluster: Der Cluster bietet lokale HA mit gemeinsamem Storage, Replica schützt über einen getrennten Speicherpfad und kann auch standortübergreifend arbeiten. Das Replikationsintervall erzeugt einen möglichen Datenverlust. Außerdem werden logische Fehler, Verschlüsselung durch Schadsoftware und versehentliche Löschungen häufig mitübertragen. Replikation verbessert daher den Wiederanlauf nach dem Verlust eines Ortes; sie ersetzt keine historischen, geschützten Recoverypunkte.

Mechanismus

Typische Stärke und Grenze

Cluster-HA

Schneller Neustart bei Hostfehler; gemeinsames Storage bleibt gemeinsame Domäne

Asynchrone Replikation

Zweites Ziel; Datenverlust bis zum letzten übertragenen Punkt möglich

Backup mit Historie

Rückkehr vor logischen Fehler; Restore dauert und muss getestet werden

Snapshot

Kurzer lokaler Rückfall; abhängig von Basisdisk und Datastore

Fehlerdomänen müssen wirklich getrennt sein

Eine zweite Kopie ist nur dann ein anderer Schutzpfad, wenn sie nicht am selben Fehler stirbt. Zwei Repositories im selben Storage-Array teilen Controller, Firmware, Administration und möglicherweise Verschlüsselungsschlüssel. Eine Replik in derselben Managementdomäne kann von demselben kompromittierten Konto gelöscht werden. CISA empfiehlt offline beziehungsweise anderweitig unerreichbare, verschlüsselte Backups und regelmäßige Integritäts- und Restoretests. Für die konkrete Plattform bedeutet das: Produktionsadministratoren dürfen nicht automatisch Aufbewahrung und Löschung aller Sicherungen kontrollieren.

• Storage- und Repository-Domäne
• Identitäts- und Rollenmodell
• Schlüssel- und Secret-Verfügbarkeit
• Standort, Energie und Netzwerk
• Backupkatalog und Orchestrierung

Recoverypunkte brauchen eine wählbare Historie

Das neueste Backup ist nicht immer das richtige. Wird eine fehlerhafte Konfiguration am Montag eingeführt und erst Donnerstag erkannt, kann jeder aktuelle Recoverypunkt den Fehler enthalten. Aufbewahrung braucht deshalb eine begründete Kombination aus Häufigkeit, Historientiefe und Unveränderbarkeit. Die Änderungsrate bestimmt Speicher- und Übertragungsbedarf; die Erkennungszeit eines Fehlers bestimmt, wie weit die Historie reichen muss. Ein nominelles RPO von fünfzehn Minuten hilft nicht, wenn alle Punkte nach wenigen Stunden überschrieben werden und der Fehler erst am Folgetag auffällt.

Ein guter Plan benennt außerdem den Recovery Point Selection Owner. Während eines Sicherheitsvorfalls kann der jüngste Punkt bereits kompromittiert sein. Dann entscheidet nicht die Backupkonsole allein, sondern Incident Response zusammen mit Anwendungs- und Datenverantwortlichen, welcher Zeitpunkt als sauber genug gilt.

Ein Restoretest braucht Isolation und Abnahme

Hyper-V unterstützt einen Test-Failover mit Start-VMFailover -AsTest. Dabei entsteht eine temporäre Test-VM, die standardmäßig nicht mit einem Netzwerk verbunden ist. Genau diese Isolation verhindert doppelte IP-Adressen, doppelte Identitäten und unbeabsichtigte Schreibzugriffe auf Produktion. Für einen aussagekräftigen Test reicht der Bootscreen dennoch nicht. Der Prüfer kontrolliert den gewählten Datenstand, Dienstabhängigkeiten, benötigte Schlüssel, Anmeldung, Hintergrundjobs und fachliche Stichproben. NIST ordnet die Validierung vor der Rückkehr in den Normalbetrieb ausdrücklich der Reconstitution zu.

Die Reihenfolge schützt vor Überschreiben und Reinfektion

Im Incident ist Geschwindigkeit wichtig, doch ein unkontrollierter Restore kann Beweise vernichten, saubere Sicherungen überschreiben oder Schadsoftware erneut an Produktion anbinden. Zuerst werden Incident-Scope, gewünschter Zielzeitpunkt und Schreibautorität geklärt. Dann entsteht ein isoliertes Recoveryziel mit eigener Netzgrenze. Erst dort werden Daten und VMs wiederhergestellt, geprüft und gegebenenfalls bereinigt. Die Umschaltung folgt einer expliziten Freigabe. Der alte Primärpfad bleibt gesperrt, bis geklärt ist, wie Daten zurückgeführt und Split Brain vermieden werden.

Für geplante Standortwechsel gilt eine andere Semantik: Ein Planned Failover kann die Quelle sauber stoppen und ausstehende Änderungen übertragen. Diese Eigenschaft darf nicht auf einen ungeplanten Ausfall übertragen werden, bei dem die Quelle nicht erreichbar oder ihr Zustand unklar ist.

Abhängigkeiten entscheiden über die echte Wiederanlaufzeit

Eine VM ist selten ein Dienst. Sie benötigt DNS, Zeit, Identität, Zertifikate, Netzwerkpolicy, Storage, Datenbanken, Lizenzdienste und manchmal externe APIs. Werden alle VMs gleichzeitig gestartet, entstehen Lastspitzen und schwer erklärbare Folgefehler. Ein Recovery-Runbook ordnet daher Wellen: zuerst die minimale Plattform, dann Datenhaltung, danach Anwendung und zuletzt nichtkritische Funktionen. Jede Welle besitzt ein messbares Gate. Ein grüner Hypervisorstatus ersetzt weder Datenbankkonsistenz noch eine erfolgreiche Transaktion aus Sicht eines Clients.

Welle

Beispiel für ein Gate

Basis

Management, Zeit und Namensauflösung sind aus dem Recoverynetz erreichbar

Daten

Datenbank öffnet erwarteten Recoverypunkt ohne ungeklärten Schreibkonflikt

Anwendung

Authentifizierter Kernprozess funktioniert Ende zu Ende

Freigabe

Service Owner bestätigt Datenstand, Sicherheit und Restabweichungen

Ein grüner Job ist ein Signal, der Nachweis ist eine Kette

Die tägliche Kontrolle beginnt bei Jobstatus, Alter des letzten Recoverypunkts, übertragenem Volumen, Repository-Kapazität und Replikationsgesundheit. Diese Telemetrie erkennt Ausfälle im Schutzmechanismus. Der eigentliche Nachweis entsteht erst durch einen Restore mit dokumentierter Dauer und Abnahme. Ein belastbares Dashboard trennt daher Schutzstatus von Recoveryfähigkeit. „Letzter Job erfolgreich“ und „letzter geprüfter Restore vor 187 Tagen“ dürfen nicht zu derselben grünen Ampel verschmelzen.

• Pro Dienst: vereinbartes RPO, RTO und Minimalumfang
• Pro Kopie: Ort, Fehlerdomäne, Aufbewahrung und Löschberechtigung
• Pro Test: Recoverypunkt, Start- und Endzeit, Daten- und Dienstabnahme
• Pro Abweichung: Owner, Frist und verbleibendes Risiko
• Pro Runbook: letzte Ausführung und bestätigte Zugänge

Die Prüfung wird als Evidence Record aufbewahrt: eindeutiger Dienst, getesteter Recoverypunkt, tatsächlicher Datenverlust, Beginn und Ende jeder Welle, verwendete Rollen sowie das Ergebnis der fachlichen Stichprobe. Screenshots allein reichen nicht, weil sie Reihenfolge und Annahmen selten erklären. Maschinenlesbare Job- und Ereignisprotokolle werden mit dem unterschriebenen Abnahmebefund verknüpft. So kann ein späterer Reviewer unterscheiden, ob der Test dieselbe Größenordnung und dieselben Abhängigkeiten wie der Vertrag abdeckte. Ändern sich Datenvolumen, Verschlüsselung, Netzsegment oder Identitätsquelle, wird der alte Nachweis nicht still weiterverwendet; der Recoveryplan erhält einen neuen Testbedarf. Evidenz hat daher ebenfalls einen Gültigkeitsbereich und ein Ablaufdatum.

Die Betriebsentscheidung als wiederholbarer Ablauf

Vor jeder Zusage wird der Dienst in Daten, VMs und Abhängigkeiten zerlegt. Danach werden Fehlerdomänen und Bedrohungen benannt: Hostverlust, Storageverlust, Standortausfall, Fehlbedienung, logische Korruption und kompromittierte Administration. Für jede relevante Klasse wird ein Schutzpfad mit RPO, RTO, Historie und Zugriffsgrenze gewählt. Ein isolierter Test misst die gesamte Kette und endet mit fachlicher Freigabe. Befunde fließen zurück in Kapazität, Runbook und Verantwortlichkeiten. So wird Recovery von einer Produktkonfiguration zu einer geübten Betriebsfähigkeit.

Auch die Aktivierung des Plans braucht eine Schwelle. NIST nennt dafür Kriterien wie erwartete Ausfalldauer oder den Verlust eines Standorts. Im eigenen Runbook sollte stehen, wer den Recoveryfall ausruft, wer Änderungen am Primärsystem stoppt und wer die neue Schreibautorität freigibt. Ohne diese Rollen wartet das Team trotz intakter Kopien auf Entscheidungen oder startet Quelle und Recoveryziel parallel. Während der Ausführung führt ein Zeitprotokoll jede Annahme, Maßnahme und Abweichung. Damit lassen sich RTO-Verfehlungen später aufteilen: War die Kopie zu langsam, fehlte ein Zugang, war die Reihenfolge falsch oder dauerte die fachliche Abnahme? Erst diese Zerlegung macht den nächsten Test besser. Nach der Rückkehr in den Normalbetrieb werden temporäre Berechtigungen entfernt, Replikationsrichtungen geprüft und Schutzjobs für die nun aktive Seite bestätigt. Ein erfolgreicher Failover ohne neu aufgebauten Schutzpfad lässt den Dienst unmittelbar nach der Rettung ungeschützt zurück. Der Abschluss des Incidents umfasst deshalb nicht nur „Dienst erreichbar“, sondern auch einen bestätigten neuen Recoverypunkt, überwachte Jobs, bereinigte Isolation und eine Entscheidung über den Rückweg.