Werbung
Ich mag Proxmox-Snapshots sehr. Vor einem riskanten OS-Upgrade, einer heiklen Konfigurationsänderung oder einem dist-upgrade auf einer VM, die ich definitiv nicht komplett neu aufsetzen will, ist ein kurzer Snapshot eine zehnsekündige Versicherungspolice. Wenn etwas fürchterlich schiefgeht, setzt ein hartes qm rollback die VM exakt wieder in ihren vorherigen Zustand zurück. Das ist unglaublich nützlich, und ich verlasse mich oft darauf.
Das Problem beginnt, wenn genau dieses Snapshot-Feature als primäre Backup-Strategie missbraucht wird. Beide lösen vollkommen unterschiedliche Probleme, und die gewaltige Lücke zwischen ihnen offenbart sich erst zum ungünstigsten denkbaren Zeitpunkt.
Was ein Snapshot eigentlich ist
Ein Proxmox-Snapshot kopiert die Festplatte der VM nicht. Er friert lediglich den aktuellen Zustand ein und fängt an, alle neuen Änderungen als Delta zu tracken. Die Originaldaten bleiben exakt dort, wo sie waren: auf exakt demselben physischen Storage-Array, auf exakt demselben Host-Node.
Genau das ist der Grund, warum Snapshots so blitzschnell erstellt sind und nicht sofort massiv zusätzlichen Speicherplatz fressen. Es ist aber auch exakt der Grund, warum sie Ihnen absolut nicht helfen werden, wenn genau dieses physische Storage-Array oder der Host-Node selbst einen katastrophalen Hardware-Ausfall erleidet.
# Snapshot vor einer riskanten Änderung erstellen
qm snapshot 101 pre-upgrade
# Wenn es schiefgeht: sofortiger Rollback
qm rollback 101 pre-upgrade
Wenn das Software-Upgrade lediglich etwas innerhalb der VM zerschießt, ist das perfekt. Dreißig Sekunden später sind Sie zurück in einem garantiert funktionierenden Zustand. Aber wenn die eigentliche Festplatte des Hosts ausfällt, oder das Mainboard des Hosts stirbt und den Boot verweigert, ist der Snapshot zusammen mit allem anderen permanent verloren. Er wurde nie irgendwohin kopiert.
Was ein echtes Backup braucht
Ein echtes Backup setzt voraus, dass die Daten physisch noch irgendwo anders existieren. Ein Problem mit der VM, dem Host-Node oder dem lokalen Storage-Array darf niemals in der Lage sein, gleichzeitig auch das Backup zu zerstören.
Das integrierte vzdump-Tool von Proxmox macht exakt das: Es schreibt eine vollständige, völlig unabhängige Kopie der VM auf ein komplett separates Ziel:
vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
Das Flag --mode snapshot tut hier etwas völlig anderes als der GUI-Snapshot, zu dem man zurückrollen würde. Es nutzt im Hintergrund nur ganz kurz Snapshot-Mechaniken, damit die VM für das Backup nicht hart gestoppt werden muss. Das eigentliche Endprodukt ist aber eine vollständige, eigenständige Archivdatei, die erfolgreich auf backup-nfs weggeschrieben wird. Dieses vma.zst-Archiv interessiert es nicht die Bohne, ob die Originalfestplatte überhaupt noch existiert.
Für alles, was über einen einzelnen isolierten Host hinausgeht, ist der Einsatz des Proxmox Backup Servers hochgradig zu empfehlen. Er fügt diesem Prozess Deduplizierung und rasante inkrementelle Backups hinzu. Das bedeutet: Tägliche Backups einer riesigen 500GB-VM erfordern nicht mehr, jede einzelne Nacht 500GB durchs Netzwerk zu schaufeln. Dennoch produziert er zu 100 % wiederherstellbare Archive, die völlig unabhängig vom Quell-Node existieren.
Der Test, der wirklich zählt
Genauso wie bei Datenbanken ist die einzige absolute Methode, um zu wissen, ob ein Proxmox-Backup gut ist, es wiederherzustellen. Idealerweise stellt man es auf einem komplett anderen physischen Storage oder einem völlig anderen Proxmox-Host wieder her als dem ursprünglichen:
qmrestore /mnt/backup-nfs/dump/vzdump-qemu-101-*.vma.zst 201 --storage local-lvm
Wenn dieser Restore erfolgreich eine VM ausspuckt, die sauber bootet und gut aussieht, ist das Backup echt. Wenn es komplett fehlschlägt, ist das etwas, das Sie verdammt noch mal jetzt an einem Dienstagmorgen wissen wollen – und nicht während eines hektischen Disaster-Recovery-Szenarios nachts um drei.
Wie ich es aufteile
Snapshots nutze ich ausschließlich für den Fall "Ich tue jetzt etwas, das ich in den nächsten zehn Minuten vielleicht rückgängig machen muss". Riskante OS-Upgrades, destruktive Software-Tests oder massive Konfigurationsänderungen. Sie sind billig, schnell und exakt das richtige Werkzeug für diesen speziellen Job.
Ich nutze vzdump mit Push auf ein separates NFS-Storage oder einen dedizierten Proxmox Backup Server für den Fall "Diese VM muss überleben, selbst wenn dieser physische Server abbrennt". Diese Backups sind geplant, liegen physisch getrennt vom Host und werden ab und zu mit einem echten Restore streng getestet.
Beides hat definitiv seine Daseinsberechtigung. Der fatale Fehler ist, die schiere Bequemlichkeit der Snapshots klammheimlich den kritischen Job des Backups übernehmen zu lassen. Das funktioniert so lange gut, bis zu dem Tag, an dem ein Problem auf Hardware-Ebene den Unterschied brutal offensichtlich und unglaublich teuer macht.
Werbung