> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/de/system-administration/cluster-recovery-after-power-outage.md). # Cluster-Wiederherstellung nach vollständigem Stromausfall ## Überblick {% hint style="info" %} **Wichtige Punkte** * Unsanfte Herunterfahrten sollten nach Möglichkeit vermieden werden, insbesondere auf Produktionssystemen. * Diese Anleitung bietet Best Practices -- zur Minderung potenzieller Probleme -- für das Einschalten des Clusters, nachdem ein unerwartetes Herunterfahren eingetreten ist. * Einschalten **Node1** Zuerst. Warten Sie 30 Sekunden bis eine Minute, dann schalten Sie die übrigen Clusterknoten ein. * Ein von Null verschiedener **Reparaturen** Zählerstand nach der Wiederherstellung ist normal; er sollte abnehmen, wenn Journal Walks abgeschlossen werden. * Wenden Sie sich an den VergeIO-Support, wenn der Reparaturzähler nach Abschluss des Journal Walks nicht wieder auf null zurückkehrt oder andere Anomalien bestehen bleiben. {% endhint %} ## Umfang Diese Anleitung behandelt das Wiederhochfahren eines VergeOS-Clusters nach einem **unsauberen Herunterfahren** -- wenn der Cluster aufgrund eines Stromausfalls, einer erschöpften USV, eines Ausfalls der Anlage oder eines ähnlichen Ereignisses abrupt die Stromversorgung verlor. Für geplante, kontrollierte Herunterfahr- und Einschaltverfahren siehe [Korrektes Verfahren zum Herunterfahren des VergeOS-Systems](/knowledge-base/de/system-administration/proper-vergeos-system-shutdown-procedure.md) und [Richtige Stromversorgungsreihenfolge](/knowledge-base/de/system-administration/proper-power-sequence-for-vergeos.md). {% hint style="warning" %} **Unsanfte Herunterfahrten nach Möglichkeit vermeiden** * Obwohl VergeOS mehrere integrierte Schutzmechanismen enthält, um die Datenintegrität zu bewahren, kann kein verteiltes Speichersystem vollständig garantieren, dass keine Datenbeschädigung auftritt, wenn Knoten abrupt und gleichzeitig die Stromversorgung verlieren. * Schreibvorgänge, die zum Zeitpunkt des Stromausfalls noch laufen, können unvollständig oder zwischen den Peers inkonsistent sein, und in manchen Fällen ist der einzige Weg zurück zur Integrität, ein Volume auf einen aktuellen Snapshot zurückzusetzen. * Außerdem treten nach unsauberen Herunterfahrten häufig Hardware-, Gast-OS- und Anwendungsprobleme auf. * Eine geeignete Strominfrastruktur -- USV-Kapazität, ausgelegt für ein sauberes Herunterfahren, redundante Netzteile und automatisches Herunterfahren bei niedrigem Akkustand -- ist der wirksamste Schutz; siehe den [Vorbeugung](#preventionmitigation) Abschnitt für Hinweise. * Wenn es trotz dieser Vorsichtsmaßnahmen doch zu einem unsauberen Herunterfahren kommt, ist das folgende Verfahren darauf ausgelegt, den Cluster sicher wieder online zu bringen und alle Integritätsprobleme sichtbar zu machen, die Aufmerksamkeit erfordern. {% endhint %} ## Voraussetzungen * Physischer oder IPMI/BMC-Zugriff auf jeden Knoten * Kenntnis davon, welcher Knoten ist **Node1** (Node1 muss zuerst gebootet werden.) * Bestätigung, dass die vorgelagerte Stromversorgung, das Netzwerk (Core-Fabric-Switches) und IPMI wiederhergestellt und stabil sind * Ein aktueller lokal oder remote replizierter Snapshot, falls Integritätsprobleme gefunden werden * Vertrautheit mit dem [vSAN-Tier-Dashboard / Journal Walks](/knowledge-base/de/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md) ## Schritte ### Was zu erwarten ist * VergeFS enthält mehrere integrierte Schutzmechanismen, die helfen, die Datenintegrität bei Stromereignissen zu bewahren -- einschließlich Schreib-Journaling, Peer-Replikation, Reparaturserver (ioGuardian) und Verifizierung beim Start. Beim Start des Controllers löst VergeFS einen **Vollständigen Journal Walk** aus, um jeden Block zu prüfen und mit den Peers abzugleichen. Diese Schutzmechanismen sind in den meisten Fällen wirksam, aber kein verteiltes Speichersystem kann vollständig garantieren, dass abrupter Stromverlust keine Beschädigung verursacht; die Verifizierung nach dem Start ist wichtig, insbesondere nach einem unsauberen Herunterfahren. * vSAN erfordert **Mindestknotenanzahl** online sein, bevor es eingebunden wird (z. B. in einem Cluster mit 4 Knoten und N+1-Schutz wird vSAN eingebunden, solange 3 Knoten online sind). Bis dieser Schwellenwert erreicht ist, bleibt der Speicher offline und VMs werden nicht starten. * Node1 bootet, hält aber vor dem Einbinden des vSAN an, bis genügend Peers beigetreten sind. * Ein von Null verschiedener **Reparaturen** Zählerstand nach der Wiederherstellung ist normal und sollte abnehmen, während der Walk fortschreitet. ### Prüfungen vor dem Einschalten {% hint style="warning" %} **Zuerst sicherstellen, dass die Infrastruktur bereit ist** Bevor Sie irgendwelche Clusterknoten einschalten, bestätigen Sie, dass zwei kritische Bedingungen erfüllt sind. Diese werden in den Voraussetzungen behandelt, aber hier sollten sie noch einmal erwähnt werden -- wenn Sie sie überspringen, kann das erheblich mehr Schaden verursachen als das ursprüngliche Herunterfahren: 1. **Die Stromversorgung der Anlage ist vollständig wiederhergestellt und stabil.** Den Cluster während anhaltender Strominstabilität hochzufahren -- Flackern, Unterspannungen oder ein zweiter Ausfall -- riskiert, das ursprüngliche Problem zu verschärfen und kann zu weiteren Problemen bei der Datenintegrität führen. 2. **Die zentralen Netzwerkswitches sind eingeschaltet und vollständig gebootet.** Enterprise-Switches können mehrere Minuten brauchen, um ihren Bootvorgang abzuschließen, ähnlich wie ein Server. Wenn Clusterknoten online gehen, bevor das Netzwerk bereit ist, können sie ihre Peers nicht entdecken, was zu Reconciliationsproblemen führen kann. {% endhint %} 3. Bestätigen Sie **die vorgelagerte Stromversorgung** ist stabil. Knoten an einer instabilen Versorgung hochzufahren, birgt das Risiko eines zweiten Ausfalls mitten in der Wiederherstellung. 4. Bestätigen Sie **die zentralen Netzwerkswitches** sind online, **vollständig gebootet**und das Inter-Node-Fabric ist aktiv. vSAN kann sich ohne es nicht neu bilden, und fortschrittliche Switches können mehrere Minuten brauchen, bis sie den Bootvorgang abschließen. 5. Prüfen Sie **IPMI/BMC** Zugriff auf jedem Knoten, damit Sie den Start bei Bedarf remote überwachen können. 6. Notieren Sie alle Knoten mit sichtbaren Hardwarefehlern (defekte Netzteile, Laufwerk-LEDs, Lüfteralarme) -- diese müssen möglicherweise vor dem erneuten Hinzufügen behoben werden. ### Einschaltsequenz Sobald Strom- und Netzwerk-Infrastruktur als bereit bestätigt sind: 1. **Schalten Sie Node1 ein.** * Beobachten Sie die Konsole/IPMI. Node1 bootet das Betriebssystem, hält aber **vor dem Einbinden des vSAN an** bis genügend Peers beitreten. 2. **Warten Sie 30 Sekunden bis eine Minute.** * Diese kurze Pause ermöglicht es Node1, mit der Initialisierung zu beginnen, bevor der Rest des Clusters eintrifft. Sie müssen nicht warten, bis Node1 vollständig seinen Halt-Zustand erreicht hat, bevor Sie fortfahren. 3. **Schalten Sie die verbleibenden Knoten ein.** * Die übrigen Knoten können zusammen (oder kurz nacheinander) eingeschaltet werden; es ist nicht nötig, sie einzeln nacheinander hochzufahren. * Das vSAN wird automatisch eingebunden, sobald eine Mindestanzahl von Knoten online ist (z. B. alle bis auf einen Knoten in einer Standard-N+1-Konfiguration). 4. **Multi-Cluster-Umgebungen:** Bringen Sie den Controller-Cluster vollständig online, bevor Sie zusätzliche Cluster einschalten. {% hint style="success" %} **Profi-Tipp** Node1 bootet zuerst und wartet, während Sie den Rest des Clusters einschalten -- das ist erwartet und kein Hängenbleiben. Das vSAN wird von selbst eingebunden, sobald genügend Peers online sind, und VergeOS übernimmt die Abstimmung automatisch; manuelle Reparaturbefehle sind nicht erforderlich. {% endhint %} ### Verifizierung nach der Wiederherstellung Sobald alle Knoten online sind und der Cluster Zeit hatte, sich zu stabilisieren, überprüfen Sie, ob alles wieder in einem gesunden Zustand ist. Da der Cluster unsauber heruntergefahren wurde, führen Sie diese Prüfungen mit besonderer Sorgfalt durch -- abruptes Stromausfall kann Probleme hinterlassen, die der Cluster nicht vollständig selbst beheben kann. Achten Sie genau auf anhaltende vSAN-Fehler, fehlgeschlagene oder in Crash-Schleifen laufende Workloads und etwaige Dateisystemfehler auf Gast-Ebene. Wenn nicht behebbarer Schaden erkannt wird, kann ein Zurücksetzen eines Volumes auf einen aktuellen Snapshot erforderlich sein. 1. **Gesamtzustand des Systems bestätigen** Ein abruptes Stromverlust erhöht das Risiko für Hardwareprobleme. Es ist wichtig, auf folgende Probleme zu achten: * Prüfen Sie die [Warnungen](/run-the-platform/operations/alarms.md) Dashboard. Bestätigen Sie, dass keine neuen Warnungen ausgelöst wurden. * Prüfen Sie die **Systemprotokolle (Haupt-Dashboard)** auf Fehler während des Bootvorgangs oder des ersten Einbindens. 2. **vSAN-Zustand prüfen** * Öffnen Sie das **Haupt-Dashboard** -- alle Statusanzeigen sollten **Grün**. * Navigieren Sie zu **System → vSAN → Ebenen** und doppelklicken Sie auf jede Ebene. * Prüfen Sie die **Status** Kachel auf dem Dashboard jeder Ebene. Der KB-Artikel [vSAN-Tier-Status-/Journal-Durchläufe verstehen](/run-the-platform/storage/vsan-diagnostics.md) enthält eine Anleitung zum Lesen der vSAN-Ebenen-Statusfelder. 3. **Laufwerkszustand prüfen** * Gehen Sie zu **System → vSAN → Laufwerke**. * Achten Sie auf Laufwerke mit Fehlern, Warnungen oder SMART-Alarmen -- dies kann auftreten, wenn Laufwerke nach einem abrupten Stromverlust nicht sauber zurückkehren. * **Defekte Laufwerke ersetzen** umgehend, um den vSAN-Datenschutz aufrechtzuerhalten. 4. **Workloads prüfen**

Verhalten beim automatischen Start von VMs

Standardmäßig sind VMs so konfiguriert, dass sie automatisch starten, wenn die Stromversorgung des Clusters wiederhergestellt wird. VMs mit einer alternativen Bei Stromverlust Einstellung müssen manuell eingeschaltet werden.

* Prüfen Sie kritische VMs: Konsole reagiert, Gast-OS gesund, Anwendungsdienste laufen. Unsanfte Herunterfahrten können Probleme innerhalb des Gast-OS und installierter Anwendungen verursachen -- achten Sie auf Dateisystemfehler, Dienste, die nicht starten, und Anwendungen, die beim Start abstürzen. * Potenzielle Kandidaten für ein Zurückrollen so früh wie möglich identifizieren -- idealerweise bevor Anwendungen wieder stark genutzt werden. {% hint style="warning" %} **Entscheidungen zum Zurückrollen von Snapshots sind zeitkritisch** Wenn das Gesamtsystem oder einzelne VMs Anzeichen von Schäden durch das unsaubere Herunterfahren zeigen, die nicht vor Ort repariert werden können, kann die Wiederherstellung aus einem Snapshot vor dem Ausfall der einzige Weg zurück zu einem gesunden Zustand sein. **Diese Entscheidung sollte so schnell wie möglich getroffen werden**, aus zwei Gründen: * **Die Aufbewahrung von Snapshots ist begrenzt.** Ein brauchbarer Snapshot vor dem Ausfall kann aus der Aufbewahrung fallen und nicht mehr verfügbar sein, wenn zu viel Zeit vergeht, bevor die Entscheidung getroffen wird. * **Neuere Daten gehen beim Zurückrollen verloren.** Je länger die betroffene VM nach dem Ausfall in Produktion genutzt wird, desto mehr legitime Arbeit nach der Wiederherstellung geht bei der Durchführung des Rollbacks verloren. {% endhint %} ## Fehlerbehebung {% hint style="warning" %} **Häufige Probleme** * **Problem:** Ein Knoten tritt dem Cluster nicht wieder bei. * **Lösung:** Prüfen Sie die IPMI-/Konsolenausgabe auf Bootfehler. Stellen Sie sicher, dass die zentrale Netzwerkschnittstelle des Knotens aktiv und von den Peers erreichbar ist. Prüfen Sie **System → Knoten → \[Knoten]** auf Status und Zuletzt-gesehen-Zeitstempel. Wenn der Knoten bootet, aber nicht beitritt, versuchen Sie nicht, ihn **nicht** zwangsweise zu entfernen -- wenden Sie sich an den Support. * **Problem:** vSAN wird nicht eingebunden / Speicher offline. * **Lösung:** Bestätigen Sie **Die Mindestanzahl an vSAN-Knoten ist online** unter **System → Knoten** (z. B. in einer Standardkonfiguration: 3 von 4 in einem 4-Knoten-Cluster, 5 von 6 in einem 6-Knoten-Cluster). Prüfen Sie die Konnektivität zwischen den Knoten (Core-Fabric-Switches, Link-Status, MTU). Wenn der Schwellenwert erreicht ist, der Speicher aber trotzdem nicht eingebunden wird, erstellen Sie ein sysdiag und wenden Sie sich an den Support. * **Problem:** Reparaturzähler bleibt hängen oder wächst. * **Lösung:** Ein kleiner, abnehmender **Reparaturen** Zählerstand ist nach der Wiederherstellung normal. Ein Zählerstand, der **nicht weiter abnimmt** oder **wächst** zeigt Blöcke an, die das vSAN nicht von Peers rekonstruieren kann. **Starten Sie keine Knoten neu.** Wenden Sie sich an den Support, bevor Sie Remediationsschritte durchführen. * **Problem:** Verdacht auf Split-Brain oder inkonsistenten Clusterzustand. * **Lösung:** Während der Wiederherstellung kann ein Netzwerkproblem dazu führen, dass zwei Knotenmengen hochkommen, ohne einander zu sehen. Wenn Sie Anzeichen dafür sehen, dass sich zwei unabhängige Cluster bilden (selten, aber nach teilweiser Netzwerkwiederherstellung möglich), **versuchen Sie nicht, sie selbst zusammenzuführen**. Erfassen Sie sysdiags von jedem Knoten und wenden Sie sich sofort an den Support. {% endhint %} ## Vorbeugung/Minderung * **USV-Dimensionierung und Abdeckung** -- dimensionieren Sie die USV so, dass sie die Dauer für ein sauberes Herunterfahren plus Reserve für jeden Knoten abdeckt. Beziehen Sie die zentralen Netzwerkswitches in dieselbe Abdeckung ein. Testen Sie die Laufzeit der USV jährlich -- Batterien altern. * **Automatisches sauberes Herunterfahren** -- Verwenden Sie UPS-Management-Software (NUT, IPMI-Skripting oder den Agenten Ihres USV-Herstellers auf einem Management-Host), um ein Ereignis mit niedrigem Akkustand zu erkennen und ein sauberes Herunterfahren des Clusters auszulösen -- entweder über die Aktion des Cluster-Dashboards, die VergeOS-API ( **Ausschalten** POST /v4/cluster\_actions`mit Body` {"cluster": \, "action": "shutdown", "params": "{}"} `), oder unseren`VRG CLI [**-Wrapper, der denselben Shutdown-Aufruf von einem Linux/macOS/Windows-Host aus skripten kann. Validieren Sie die Automatisierung in einem Wartungsfenster, bevor Sie sich darauf verlassen.**](https://github.com/verge-io/vrg) "VM-Einstellungen bei Stromausfall" * **"VM-Einstellungen bei Stromausfall"** -- konfigurieren Sie das Verhalten jeder VM bewusst, damit der Zustand nach der Wiederherstellung vorhersehbar ist. Drei Optionen: * ***Letzter Zustand*** -- VM wird nur eingeschaltet, wenn sie zum Zeitpunkt des Stromausfalls eingeschaltet war * ***Ausgeschaltet lassen*** -- VM bleibt ausgeschaltet, wenn die Stromversorgung wiederhergestellt wird, unabhängig vom vorherigen Zustand * ***Einschalten*** -- VM wird eingeschaltet, wenn die Stromversorgung wiederhergestellt wird, unabhängig vom vorherigen Zustand * **Reparaturserver (ioGuardian)** -- ein konfigurierter [Reparaturserver](/automate-protect-and-extend/backup-and-dr/repair-server.md) gibt VergeFS eine alternative Quelle für fehlende Blöcke, falls Peers sie nach einem Ausfall nicht bereitstellen können. Er wird aus einer vorhandenen ausgehenden Site-Sync-Konfiguration aufgebaut und zieht benötigte Blöcke von einem synchronisierten entfernten VergeOS-System. Reparaturserver werden für jede Produktionsbereitstellung dringend empfohlen. * **Ausreichende Snapshot-Rotation** -- pflegen Sie einen Aufbewahrungsplan für Snapshots, der aktuelle Snapshots vor dem Ereignis für einen erforderlichen Rollback verfügbar hält. Das Replizieren von Snapshots an einen entfernten Standort wird ebenfalls als Teil einer umfassenden Datenschutzstrategie empfohlen. ## Wann Sie den Support kontaktieren sollten Eröffnen Sie ein Support-Ticket **bevor** Sie Knoten neu starten oder andere wesentliche Änderungen vornehmen, wenn einer der folgenden Punkte zutrifft: * vSAN wird nicht eingebunden, nachdem N Knoten online sind (z. B. die volle Knotenanzahl minus eins in einer Standard-N+1-Redundanz) * Eine Ebene zeigt **Redundant: false** über einen längeren Zeitraum, nachdem Full Walks abgeschlossen sind * Der **Reparaturen** Zählerstand bleibt hängen oder wächst * Eine Warnung wegen hängender Reparaturen ist vorhanden (VergeOS v26+) * Mehrere Laufwerke melden nach der Wiederherstellung Fehler * Sie vermuten Split-Brain oder einen inkonsistenten Clusterzustand * Ein Knoten kann nicht wieder beitreten, und die Ursache ist nicht offensichtlich hardwarebedingt ## Erstellen eines Systemdiagnoseberichts für den Support Bevor Sie das Ticket eröffnen, erfassen Sie ein sysdiag und hängen Sie es an (oder senden Sie es direkt an den Support): Siehe [Systemdiagnosen erstellen](/knowledge-base/de/troubleshooting/generating-system-diagnostics.md) und die vollständige [Systemdiagnose](/run-the-platform/system-administration/diagnostics.md) Referenz. ## Zusätzliche Ressourcen * [Richtige Stromversorgungsreihenfolge](/knowledge-base/de/system-administration/proper-power-sequence-for-vergeos.md) * [Korrektes Verfahren zum Herunterfahren des VergeOS-Systems](/knowledge-base/de/system-administration/proper-vergeos-system-shutdown-procedure.md) * [Journal Walks und vSAN-Tier-Status verstehen](/knowledge-base/de/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md) * [Systemdiagnosen erstellen](/knowledge-base/de/troubleshooting/generating-system-diagnostics.md) * [Reparaturserver (ioGuardian)](/automate-protect-and-extend/backup-and-dr/repair-server.md) * [vSAN-Diagnoseleitfaden](/run-the-platform/storage/vsan-diagnostics.md) ## Feedback {% hint style="info" %} **Brauchen Sie Hilfe?** Wenn Sie weitere Unterstützung benötigen oder Fragen zu diesem Artikel haben, zögern Sie bitte nicht, sich an unser Support-Team zu wenden. {% endhint %} *** {% hint style="info" %} **Dokumentinformationen** * Zuletzt aktualisiert: 2026-05-08 * vergeOS-Version: 26.0+ {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verge.io/knowledge-base/de/system-administration/cluster-recovery-after-power-outage.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.