Proxmox-Backup-Checkliste für VMs, LXC und Host-Konfiguration

Eine erfolgreiche Proxmox-Gastsicherung ist unvollständig, wenn Bind-Mounts, Anwendungsstatus, Host-Konfiguration, Schlüssel oder das Repository dieselbe Fehlerdomäne teilen.

Bei einem Heimserver, auf dem VMs und LXC-Container laufen, umfasst die Wiederherstellung Gastfestplatten, externe Daten, Datenbanken, Netzwerke, Speicherdefinitionen, Firewall-Status, Passthrough-Zuordnungen, Zugangsdaten und den Prozess zum Wiederaufbau eines leeren Hosts. Erfassen Sie diese Ebenen, bevor Sie Sicherungsmodi auswählen, bewahren Sie eine Kopie außerhalb des Hosts auf und testen Sie sowohl die Wiederherstellung eines Gasts als auch einen Wiederherstellungspfad auf Host-Ebene. Beenden Sie die Ausmusterung älterer Wiederherstellungspunkte, sobald einer der Tests eine nicht dokumentierte Abhängigkeit offenlegt.

Jede Wiederherstellungsebene und Fehlerdomäne erfassen

Listen Sie jede VM und jeden LXC, virtuelle Laufwerke, Snapshots, Bind-Mounts, Passthrough-Geräte, Anwendungsdatenbanken, externe NAS-Freigaben, Verschlüsselungsschlüssel und Sicherungsaufträge auf. Erfassen Sie anschließend die Host-Netzwerke, Speicherdefinitionen, den Cluster- oder Standalone-Status, Firewall-Regeln, geplante Aufgaben, Paketquellen und Hinweise, die zum Wiederherstellen von Hardware-Zuordnungen erforderlich sind.

Proxmox VE kann Gastsicherungen auf lokale Ziele sowie auf NFS- oder CIFS-Ziele schreiben, während ein dedizierter Sicherungsserver zusätzliche Repository-Funktionen bietet. Eine unabhängige Erklärung zu Auswahlmöglichkeiten für Gastsicherungsziele erläutert diese Trennung. Keines der Ziele nimmt jedoch automatisch Daten auf, die aus anderer Quelle in einen Gast eingebunden sind, oder die Aufzeichnungen zum Wiederaufbau des Hosts.

Legen Sie die Fehlerdomänen fest, bevor Sie die Aufbewahrung auswählen. Ein Repository auf demselben Host, in demselben Pool, an derselben USV oder mit denselben Administratorzugangsdaten wie die Produktion ist ein nützlicher Wiederherstellungspunkt, aber nicht die unabhängige Kopie, die Sie bei Hostverlust, Diebstahl, Ransomware oder versehentlicher Zerstörung des Pools benötigen.

Sicherungsmodus an jede Arbeitslast anpassen

Klassifizieren Sie Gastsysteme als zustandslos, Dateiserver, transaktionale Datenbank oder gemischte Anwendung. Dokumentieren Sie, ob der Sicherungsmodus einen anwendungskonsistenten oder nur einen absturzkonsistenten Zustand liefert, welcher Gast-Agent oder Hook beteiligt ist und welche externen Pfade außerhalb des Archivs bleiben.

Nutzen Sie den ZimaSpace-Workflow zum Anpassen der Sicherungsmodi an die Arbeitslasten, um je nach Arbeitslast das Stoppen, Anhalten oder Snapshot-Verhalten auszuwählen. Eine ruhige VM-Desktopumgebung und eine Datenbank, die Schreibvorgänge verarbeitet, sollten nicht dieselbe Annahme übernehmen, nur weil beide Aufträge erfolgreich abgeschlossen wurden.

Erstellen Sie für LXC-Bind-Mounts und vom Host eingebundene Freigaben explizite Datei- oder Anwendungssicherungen mit demselben Wiederherstellungszeitpunkt, wenn die Konsistenz dies erfordert. Wenn sich der erforderliche Zustand nicht koordinieren lässt, dokumentieren Sie die Lücke und verwenden Sie ein Wartungsfenster, anstatt den Eindruck zu erwecken, das Gastarchiv sei vollständig.

Host-Konfiguration und Repository schützen

Exportieren Sie ein lesbares Host-Wiederherstellungspaket mit Netzwerkschnittstellen, Speicherkonfiguration, VM- und Containerdefinitionen, Firewall-Regeln, relevanten Clusterdateien, geplanten Aufträgen, Repository-Endpunkten und einer Paket-/Versionsübersicht. Bewahren Sie Geheimnisse und Verschlüsselungsschlüssel in einem geschützten Zugangsdatensystem auf, nicht in einer öffentlich zugänglichen Wiederherstellungsnotiz.

Eine Proxmox-Community-Diskussion zur Sicherung stellt die konkrete Frage Was ist mit der Systemkonfiguration?, die nach der Konfiguration von VM- und Containerarchiven übrig bleibt. Betrachten Sie diese Frage als Hinweis auf den Umfang: Der Schutz der Host-Konfiguration ist von der Gastsicherung getrennt und muss als Hilfe für den Wiederaufbau getestet werden.

Führen Sie Repository-Überprüfungen, eine Vorschau der Aufbewahrung und Kopien außerhalb des Hosts nach Zeitplänen aus, die nicht mit destruktiven Wartungsarbeiten kollidieren können. Lösen Sie bei verpassten Aufträgen, fehlgeschlagener Überprüfung, Kapazitätsengpässen und einem unveränderten Repository Alarm aus, während die Produktion weiterhin aktiv ist.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Einen Gast wiederherstellen und den Wiederaufbau des Hosts proben

Stellen Sie eine VM und einen LXC mit isolierten IDs und Netzwerken wieder her. Starten Sie Datenbanken vor den abhängigen Anwendungen, binden Sie kopierte Bind-Mount-Daten ein und überprüfen Sie Anmeldung, Dienstzustand, aktuelle Datensätze, Dateiberechtigungen und einen zweiten Neustart. Verbinden Sie Testgäste nicht mit Schreibzugriff mit dem Produktionsspeicher.

Proben Sie anschließend die Wiederherstellung eines leeren Hosts auf Ersatzhardware oder einem Wegwerf-Host innerhalb eines verschachtelten Systems: Installieren Sie den Hypervisor, stellen Sie Netzwerk- und Speicherdefinitionen bewusst wieder her, binden Sie das Repository ein und stellen Sie einen kritischen Gast wieder her. Dokumentieren Sie jede nicht erfasste Abhängigkeit und aktualisieren Sie das Runbook.

Die Checkliste ist erfüllt, wenn unabhängige Kopien vorhanden sind, die Überprüfung aktuell ist, Gastwiederherstellungen funktionieren und der Host ohne die ausgefallene Startfestplatte wieder aufgebaut werden kann. Eskalieren Sie fehlende Schlüssel, inkonsistente Datenbanken, Repository-Fehler oder Passthrough-Zuordnungen, die sich nicht reproduzieren lassen, bevor Sie einen älteren Wiederherstellungspunkt ausmustern.