Wiederanlauf planen: WZ-IT unterstützt bei Proxmox Disaster Recovery. Ein abgegrenzter Restore-Test prüft einen vereinbarten Wiederherstellungsweg. Erstgespräch.
Ein Disaster-Recovery-Plan beschreibt, welche Systeme nach welchem Ausfall aus welchem Datenstand wieder anlaufen sollen. Die folgenden Muster sind eine Planungshilfe und keine Zusage einer Wiederanlaufzeit. Stand: Oktober 2026.
Inhalt
- Ziele und Ausfallgrenzen
- Drei technische Muster
- Multi-Site und Stretched Ceph
- Runbook für den Wiederanlauf
- Abnahme und Angebotsweg
- Quellen
Ziele und Ausfallgrenzen
Legen Sie je Anwendung den maximal tolerierten Datenverlust als RPO und die tolerierte Unterbrechung als RTO fest. Die Ziele sind zunächst Anforderungen. Ob die Architektur sie erfüllt, wird im vereinbarten Szenario geprüft. Erfassen Sie getrennt Hostausfall, Storage-Verlust, Standortverlust und unbrauchbare Daten. Für jeden Fall braucht es eine erreichbare Kopie und einen kontrollierten Startpfad.
HA und Fencing koordinieren den Wiederanlauf von HA-Ressourcen im Cluster. Ein Cluster am selben Standort beseitigt dessen gemeinsame Ausfallursachen nicht. Dokumentieren Sie deshalb auch Strom, Switches, Administratorzugänge und Backup-Abhängigkeiten.
Drei technische Muster
| Muster | Datenweg | Grenze im Plan |
|---|---|---|
| Backup und Restore | Aufbewahrte Gast-Backups, separate Offsite-Kopie, Ersatz-PVE | Host, Netze und Anwendungen müssen wiederhergestellt werden |
| ZFS-Replikation | Asynchrone Kopien lokaler ZFS-Gastvolumes auf andere Cluster-Nodes | Letzter erfolgreicher Sync begrenzt den verfügbaren Datenstand |
| Stretched Ceph | Standortübergreifende Storage-Platzierung mit eigenem Quorum-Design | Storage-Verfügbarkeit ersetzt keine unabhängigen Backups |
Die PVE-Backup-Dokumentation beschreibt Gast-Backups und Restore. Für den Ausfall der PVE-Installation ist zusätzlich der Host-Wiederaufbau erforderlich. Ein PBS, der ausschließlich auf der ausgefallenen Infrastruktur erreichbar war, ist noch kein unabhängiger Recovery-Pfad; planen Sie dessen Erreichbarkeit und die Offsite-Kopie mit.
Die Storage-Replikation arbeitet mit lokalem ZFS. Bei HA mit Replikation können Schreibvorgänge seit dem letzten Sync verloren gehen. Eine Replik ist deshalb kein Versprechen für RPO null. Nach einem Fehler müssen Sicherungsstand und Anwendungskonsistenz gesondert bewertet werden.
Multi-Site und Stretched Ceph
Unterscheiden Sie zwei unabhängige Cluster mit geplantem Restore beziehungsweise Datentransfer von einem gemeinsamen Cluster über Standorte. Für einen gemeinsamen PVE-Cluster gelten weiterhin die Corosync-Netzanforderungen. Eine Standortkopplung mit genügend Bandbreite kann dennoch zu hohe oder schwankende Latenz haben. Die providerneutrale Netzplanung erklärt die Trennung.
Der ausdrücklich aktivierte Ceph-Stretch-Modus verteilt OSDs auf genau zwei Datensites und verwendet zwei Monitore je Datensite sowie einen Tiebreaker-Monitor an einem dritten Ort. Er verlangt eine dazu passende CRUSH-Regel und vier Replikate, zwei je Datensite; Erasure-Coding-Pools sind in diesem Modus ausgeschlossen. Diese Anforderungen gelten für den dokumentierten Stretch-Modus, nicht pauschal für jede verteilte Ceph-Topologie.
Das Corosync-Quorum ist zusätzlich zu planen. Ein QDevice ersetzt weder Ceph-Monitore noch Datenkopien. Verbindungsverlust bei weiterlaufenden Standorten muss ausdrücklich im Testplan stehen. Stretched Ceph ist kein automatischer Schutz vor Löschung oder kompromittierten Administrationszugängen. Änderungen am Stretch-Modus gehören in eine versionsbezogene Planung, nicht in ein allgemeines Notfallrezept.
Runbook für den Wiederanlauf
Das folgende Muster wird mit konkreten Systemen, Verantwortlichen und Nachweisen ausgefüllt:
| Schritt | Einzutragender Inhalt |
|---|---|
| Freigabe | Ausfallszenario, Entscheider, Abbruchkriterium und Kommunikation |
| Quelle sichern | Alten Standort oder Host kontrolliert abschalten beziehungsweise einzäunen; Doppelstarts ausschließen |
| Grundlagen | Managementzugang, DNS, Zeitdienst, Netz, Storage und PBS erreichbar machen |
| Datenstand wählen | Verfügbare Sicherung oder Replik, Schlüssel, Konsistenz und fehlende Änderungen bewerten |
| Wiederanlauf | Infrastrukturabhängigkeiten vor Anwendungssystemen starten; genaue Reihenfolge benennen |
| Abnahme | Datenstand, Anmeldung, fachlicher Ablauf, Zugriffe und neue Backups nachweisen |
| Rückkehr | Schreibhoheit festlegen, Daten abgleichen und Rückverlagerung separat freigeben |
Das pmxcfs-Recovery-Kapitel verlangt bei manueller Gastübernahme vom ausgefallenen Node dessen sichere Abschaltung beziehungsweise Fencing. Eine Konfigurationsdatei allein macht fehlende lokale Gastdatenträger nicht verfügbar. Diese Voraussetzungen gehören vor jeden manuellen Start.
Abnahme und Angebotsweg
Protokollieren Sie den verwendeten Datenstand, den Beginn des Wiederanlaufs, die fachliche Freigabe und offene Abhängigkeiten. Eine tatsächlich gemessene Dauer gilt für die geprüfte Konfiguration und den gewählten Fall. Fehlende Schlüssel, unzugängliche Backups oder nicht verfügbare Ersatzkapazität sind Befunde, keine bestandenen Teiltests.
Für Ziele, Architektur und Runbook führt der Weg zu Disaster Recovery. Für die isolierte Prüfung eines Sicherungsstands zum Restore-Test. Umfang und Prüfkriterien werden vereinbart.
