So schützen Sie Backups virtueller Maschinen während der Wartung des Host-Speichers

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Schützen Sie Sicherungen virtueller Maschinen während der Wartung des Host-Speichers, indem Sie zunächst neue Schreibvorgänge stoppen, vorhandene Wiederherstellungspunkte überprüfen und mindestens eine nutzbare Kopie außerhalb des gewarteten Speichers aufbewahren.

Auf einem Heimserver oder kleinen NAS findet die Wartung häufig an denselben Laufwerken, Pools, HBAs, Gehäusen oder Datastores statt, die auch die VM-Sicherungen enthalten. Deshalb ist die sichere Reihenfolge wichtiger als der Name des verwendeten Tools: Frieren Sie Sicherungsaktivitäten ein, stellen Sie sicher, dass die Wiederherstellungspunkte lesbar sind, machen Sie die Wartung rückgängig machbar und greifen Sie erst danach in die Speicherschicht des Hosts ein.

Ermitteln Sie, welche Sicherungen vom zu wartenden Speicher abhängen

Beginnen Sie damit, jede VM, jeden Container, jeden Sicherungsauftrag, jedes Repository, jeden Snapshot-Speicherort und jedes Replikationsziel aufzulisten, das aus dem zu wartenden Speicher liest oder in ihn schreibt. Die entscheidende Frage ist nicht, wo die VM ausgeführt wird, sondern ob die Sicherungskette oder der Wiederherstellungskatalog von der Komponente abhängt, die Sie gleich außer Betrieb nehmen.

Eine häufige Falle im Heimlabor besteht darin, die VM-Laufwerke und das Sicherungs-Repository in verschiedenen Datasets, aber im selben Pool, USB-Gehäuse, Controller oder auf derselben Maschine aufzubewahren. Das verbessert zwar die Organisation, schützt die Sicherung jedoch nicht, wenn das Wartungsrisiko den gesamten Pool, Controller oder Host betrifft.

Wenn ein Wiederherstellungspfad vom selben Speicher abhängt, markieren Sie diese Sicherung für das Wartungsfenster als nicht verfügbar. Fahren Sie erst fort, wenn eine zweite Kopie, eine entfernte Kopie oder ein getesteter Export vorhanden ist, der das zu wartende Gerät nicht benötigt.

Versetzen Sie das Sicherungsziel in einen Zustand ohne neue Schreibvorgänge

Das sicherste Wartungsfenster beginnt damit, neue Schreibvorgänge für Sicherungen, Bereinigungsoperationen, Komprimierung, Replikation und Garbage Collection zu verhindern, während die Speicherschicht geändert wird. Ein ruhiges Repository lässt sich leichter beurteilen als eines, das im Hintergrund Indizes oder Datenblöcke neu schreibt.

Der Proxmox Backup Server unterstützt schreibgeschützte und Offline-Wartungsmodi für Datastores. Dabei dürfen widersprüchliche Vorgänge noch abgeschlossen werden, bevor der Modus wirksam wird. Dieser Unterschied ist wichtig, da der schreibgeschützte Modus Wiederherstellungen möglicherweise weiterhin zulässt, während der Offline-Modus sowohl Lese- als auch Schreibvorgänge blockiert.

Verwenden Sie den am wenigsten störenden Modus, der die Aufgabe schützt. Für Firmware-Updates, Verkabelungsarbeiten, den Import eines Pools, den Austausch eines Laufwerks oder die Reparatur eines Dateisystems ist der Offline-Modus normalerweise sicherer. Bei Prüfungen auf Repository-Seite, für die lediglich neue Schreibvorgänge gestoppt werden müssen, kann der schreibgeschützte Modus ausreichen. Verlassen Sie sich nicht auf Ihr Gedächtnis – dokumentieren Sie den Modus und die deaktivierten Aufträge.

Überprüfen Sie die Wiederherstellungspunkte, bevor Sie den Speicher verschieben oder reparieren

Eine Sicherung, die nicht überprüft wurde, ist lediglich ein möglicher Wiederherstellungspunkt. Führen Sie vor der Wartung die Verifizierung des verwendeten Tools aus oder stellen Sie zumindest testweise isoliert eine Wiederherstellung aus den neuesten und ältesten Wiederherstellungspunkten her, die Sie behalten möchten.

Der Proxmox Backup Server bietet geplante Verifizierungsaufträge, sodass Sicherungsdaten regelmäßig geprüft werden können, anstatt ihnen erst zum Zeitpunkt der Wiederherstellung zu vertrauen. Für Wartungsarbeiten ist ein aktuelles Verifizierungsergebnis hilfreicher als eine erfolgreiche Sicherungsbenachrichtigung von vor mehreren Wochen.

Wenn die Verifizierung fehlschlägt, stoppen Sie den Wartungsplan und reparieren Sie zuerst die Sicherungsdaten. Wenn nur ein Wiederherstellungspunkt die Verifizierung besteht, halten Sie ihn isoliert und führen Sie keine Bereinigung oder Komprimierung durch, bis ein zweiter funktionierender Wiederherstellungspfad vorhanden ist.

-15% OFF

Bewahren Sie eine Wiederherstellungskopie außerhalb des Wartungsbereichs auf

Bevor Sie Laufwerke, Pools, Controller, Einhängeoptionen oder das Repository-Layout ändern, verschieben Sie mindestens eine Wiederherstellungskopie außerhalb des möglichen Schadensbereichs. Dabei kann es sich um ein Wechsellaufwerk, ein anderes NAS, einen entfernten Proxmox Backup Server, Cloud-Objektspeicher oder einen temporären Export der wichtigsten VMs handeln.

Die Dokumentation zu Veeams Scale-out-Repository behandelt die Repository-Wartung als zustandsabhängigen Vorgang und erklärt, dass ein Extent für Wartungsarbeiten wie das Patchen oder Aktualisieren in den Wartungsmodus versetzt werden kann. Die zugrunde liegende Lehre gilt allgemein: Wartungsarbeiten sollten mit dem Repository-Zustand koordiniert werden und nicht als unkontrollierter Speicherereignis erfolgen.

Wählen Sie für einen Heimserver die Kopie, die Ihrem tatsächlichen Wiederherstellungsbedarf entspricht. Für eine kritische VM kann ein bootfähiger Export besser geeignet sein, während sich für viele VMs die Replikation deduplizierter Sicherungen anbietet. Die Kopie ist erst dann ausreichend, wenn Sie wissen, wo sie sich befindet, wie sie entsperrt wird und wie Sie daraus wiederherstellen können, ohne den gewarteten Host-Speicher zu benötigen.

Aktivieren Sie Aufträge erst nach einer Prüfung des Wiederherstellungspfads

Aktivieren Sie nach der Wartung nicht sofort alle geplanten Aufträge wieder. Binden Sie den Speicher zunächst sauber ein oder importieren Sie ihn, prüfen Sie die Besitzverhältnisse des Repositorys und den freien Speicherplatz und führen Sie anschließend einen Lesetest mit vorhandenen Sicherungen durch, bevor Sie neue Schreibvorgänge zulassen.

Wartungsaufgaben für Sicherungen können sehr I/O-intensiv sein. Die Best Practices von Veeam beschreiben die Wartung vollständiger Sicherungsdateien als einen Prozess, der eine neue vollständige Sicherungsdatei erstellt und anschließend das Original löscht. Solche Vorgänge sollten Sie nicht mit Speicherreparaturen oder instabilen Laufwerken überschneiden lassen.

Fahren Sie die Dienste in dieser Reihenfolge wieder hoch: Speicherzustand, Lesezugriff auf das Repository, Auflistung der Wiederherstellungspunkte, kleiner Wiederherstellungstest und erst dann geplante Schreibvorgänge. Wenn ein Schritt langsam, unvollständig oder inkonsistent ist, lassen Sie die Aufträge deaktiviert und untersuchen Sie das Problem, bevor eine neue Sicherungskette den Fehler verdeckt.

FAQ

Kann ich VM-Sicherungen weiterlaufen lassen, während ich ein Laufwerk im Host austausche?

Nur wenn sich das Sicherungs-Repository und der Wiederherstellungspfad eindeutig außerhalb des gewarteten Speichers befinden. Wenn das Sicherungsziel denselben Pool, Controller, dasselbe Gehäuse oder dieselbe Host-Abhängigkeit nutzt, stoppen Sie zuerst neue Schreibvorgänge.

Reicht ein VM-Snapshot als Schutz vor der Speicherwartung aus?

Nein. Ein Snapshot auf demselben Speicher kann bei einer kurzfristigen Rücksetzung helfen, schützt jedoch nicht vor einem Ausfall des Pools, Controllers, Gehäuses oder Hosts. Bewahren Sie eine unabhängige Sicherungskopie auf.

Wenn Ihre Wartung auch die ZFS-Replikation umfasst, prüfen Sie vor dem Wartungsfenster das Aufbewahrungsverhalten und den freien Speicherplatz. Ein voller Ziel-Pool kann eine einfache Wartungsaufgabe in dasselbe Fehlerszenario verwandeln, das im ZimaSpace-Leitfaden zum Verhindern einer Überfüllung des Ziel-Pools durch Snapshot-Replikation beschrieben wird.

Support & Tipps

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.