Proxmox-Snapshots sind keine Backups

Ich mag Proxmox-Snapshots. Vor einem riskanten Upgrade, einer Config-Änderung, bei der ich mir nicht ganz sicher bin, oder einem dist-upgrade auf einer VM, die ich lieber nicht von Grund auf neu aufsetzen möchte, ist ein Snapshot eine Zehn-Sekunden-Versicherung. Geht etwas schief, bringt qm rollback die VM exakt in den vorherigen Zustand zurück. Das ist wirklich nützlich, und ich nutze es oft.

Das Problem entsteht, wenn genau dieser Snapshot zur Backup-Strategie erklärt wird, denn beide lösen unterschiedliche Probleme, und die Lücke zwischen ihnen zeigt sich erst im denkbar ungünstigsten Moment.

Was ein Snapshot tatsächlich ist

Ein Proxmox-Snapshot kopiert die Disk der VM nicht. Er friert den aktuellen Zustand ein und beginnt, Änderungen als Delta zu erfassen, die ursprünglichen Daten bleiben exakt dort, wo sie waren, auf demselben Storage, auf demselben Host. Genau deshalb sind Snapshots schnell erstellt und belegen nicht sofort zusätzlichen Platz, und genau deshalb helfen sie auch nicht, wenn dieser Storage oder dieser Host ein Problem hat.

# Snapshot vor einer riskanten Änderung
qm snapshot 101 pre-upgrade

# Falls etwas schiefgeht, zurückrollen
qm rollback 101 pre-upgrade

Wenn das Upgrade etwas innerhalb der VM zerstört, ist das perfekt, dreißig Sekunden, und man ist wieder bei einem bekannt guten Zustand. Fällt die Disk des Hosts aus, oder kommt der Host selbst nicht wieder hoch, ist der Snapshot zusammen mit allem anderen weg, weil er nie irgendwo anders existiert hat.

Was ein echtes Backup braucht

Ein Backup muss irgendwo existieren, wo ein Problem mit der VM, dem Host oder dem Storage nicht auch das Backup mitnimmt. Proxmox' eingebautes vzdump macht genau das, indem es eine vollständige Kopie der VM auf ein separates Ziel schreibt:

vzdump 101 --storage backup-nfs --mode snapshot --compress zstd

Das --mode snapshot macht hier etwas anderes als ein Proxmox-Snapshot, auf den man zurückrollt, es nutzt kurzzeitig Snapshot-Mechanismen, damit die VM nicht angehalten werden muss, aber die Ausgabe ist ein vollständiges, eigenständiges Archiv auf backup-nfs. Dieses Archiv ist nicht davon abhängig, dass die ursprüngliche Disk noch existiert.

Für mehr als einen einzelnen Host lohnt sich der Proxmox Backup Server, der darauf Deduplizierung und inkrementelle Backups aufsetzt, sodass tägliche Backups einer großen VM nicht täglich vollständige Kopien bedeuten, während die Ausgaben trotzdem wiederherstellbare Archive sind, die unabhängig von der Quelle existieren.

Der Test, der tatsächlich zählt

Genau wie bei Datenbank-Backups ist der einzige Weg, zu wissen, dass ein Proxmox-Backup gut ist, es wiederherzustellen, idealerweise auf einem anderen Storage oder einem anderen Host als dem ursprünglichen:

qmrestore /mnt/backup-nfs/dump/vzdump-qemu-101-*.vma.zst 201 --storage local-lvm

Bootet die wiederhergestellte VM und sieht alles richtig aus, ist das Backup echt. Wenn nicht, ist das etwas, das man jetzt wissen sollte, nicht erst bei einer echten Wiederherstellung.

Die Aufteilung, die ich nutze

Snapshots für den Fall "ich mache gerade etwas, das ich in den nächsten zehn Minuten vielleicht rückgängig machen muss": Upgrades, riskante Config-Änderungen, das Testen von etwas Destruktivem. Sie sind billig, schnell und genau richtig für diesen Job. vzdump auf separaten Storage, oder Proxmox Backup Server, für den Fall "diese VM muss noch existieren, selbst wenn dieser Host es nicht mehr tut": geplant, außerhalb des Hosts, und ab und zu mit einer echten Wiederherstellung getestet.

Beide haben ihren Platz. Der Fehler ist, die Bequemlichkeit des ersten leise die Aufgabe des zweiten übernehmen zu lassen, bis zu dem Tag, an dem ein Problem auf Host-Ebene den Unterschied sehr deutlich, und sehr teuer macht.