Proxmox-Snapshots richtig nutzen – und ihre Grenzen

Snapshots sind die am häufigsten missverstandene Funktion in Proxmox. Sie sehen aus wie eine Sicherung, verhalten sich manchmal wie eine – und sind im entscheidenden Moment keine.

Dieser Artikel klärt drei Dinge: was ein Snapshot technisch ist, welche Speicherarten ihn können, und warum er ein Werkzeug für Minuten und Stunden ist, nicht für Wochen.

Was ein Snapshot ist

Ein eingefrorener Stand der virtuellen Datenträger zu einem Zeitpunkt. Kein Kopiervorgang – deshalb ist er sofort fertig, unabhängig von der Datenmenge.

Was danach geschieht, hängt vom Speicher ab, läuft aber immer auf dasselbe hinaus: Der alte Stand wird festgehalten, neue Schreibvorgänge landen woanders. Der Snapshot belegt anfangs praktisch nichts und wächst mit jeder Änderung.

Daraus folgt die wichtigste Eigenschaft, und sie ist zugleich die Falle: Ein Snapshot liegt auf demselben Speicher wie das Original. Fällt der Datenträger aus, sind Original und Snapshot gleichzeitig weg.

Snapshot ist keine Sicherung

Diese Unterscheidung entscheidet im Ernstfall über alles.

	Snapshot	Sicherung
Liegt auf	demselben Speicher	einem anderen System
Übersteht Ausfall des Datenträgers	nein	ja
Übersteht Löschung der VM	nein, verschwindet mit	ja
Übersteht Verschlüsselungstrojaner	nur mit Sperre gegen Löschen	ja, bei richtigem Aufbau
Dauer	sofort	je nach Datenmenge
Rückkehr zu	genau diesem Stand	jedem gesicherten Stand

Ein Angreifer mit Verwaltungsrechten auf dem Wirt löscht Snapshots mit demselben Klick, mit dem er die VM löscht. Genau deshalb ist die Trennung der Systeme der Kern jeder brauchbaren Sicherung – nachzulesen in der 3-2-1-Backup-Strategie und, mit Blick auf Erpressung, in Ransomware-sichere Backups.

Snapshots sind trotzdem nützlich. Nur eben für etwas anderes.

Welche Speicher Snapshots können

Der Punkt, an dem die Funktion in der Oberfläche ausgegraut ist und niemand weiß, warum.

Speicherart	Snapshots	Anmerkung
ZFS	ja	die schnellste und sparsamste Variante
LVM-Thin	ja	Vorgabe bei Installation auf ext4
Ceph RBD	ja
Verzeichnis / NFS / SMB mit qcow2	ja	Snapshots stecken in der Abbilddatei
Verzeichnis / NFS / SMB mit raw	nein	häufigste Ursache
LVM ohne Thin-Bereitstellung	nein

Die vorletzte Zeile ist der häufigste Fall. Eine VM auf einem NFS-Speicher mit Rohabbildern kann keine Snapshots. Das Format wurde beim Anlegen des Datenträgers gewählt und lässt sich nachträglich nur durch Verschieben ändern.

Eine Übersicht, welcher Speicher wofür taugt, steht im Einstiegsartikel.

Mit oder ohne Arbeitsspeicher

Beim Anlegen fragt Proxmox, ob der Arbeitsspeicher mitgesichert werden soll.

Ohne ist der Snapshot sofort fertig. Beim Zurückkehren startet die VM neu – als wäre sie in diesem Moment ausgeschaltet worden. Für die meisten Systeme unproblematisch; Datenbanken sollten für diesen Fall vorbereitet sein.

Mit wird der gesamte belegte Arbeitsspeicher weggeschrieben. Das dauert – die VM steht währenddessen kurz –, und der Snapshot belegt entsprechend Platz. Dafür kommt die VM beim Zurückkehren laufend zurück, mit offenen Verbindungen und allem.

Faustregel: Vor einem Update ohne Arbeitsspeicher. Vor einem Eingriff, bei dem der laufende Zustand zählt, mit.

Zwei Einschränkungen: Bei durchgereichter Hardware geht der Arbeitsspeicher-Snapshot nicht – der Zustand der Karte lässt sich nicht wegschreiben, siehe GPU-Passthrough. Und Container kennen keinen Arbeitsspeicher-Snapshot, nur den Dateisystemstand.

Wofür Snapshots wirklich taugen

Vor einem Update

Der Hauptanwendungsfall. Snapshot, Update, prüfen, Snapshot löschen. Geht etwas schief, ist die Rückkehr eine Sache von Sekunden.

Wichtig ist der letzte Schritt. Der Snapshot gehört nach der Prüfung gelöscht, nicht „vorsichtshalber“ behalten.

Vor einer riskanten Änderung

Konfigurationsumbau, Migration einer Anwendung, ein Eingriff, den man selten macht. Dasselbe Muster.

Als Grundlage der Replikation

Die Replikation zwischen Cluster-Knoten setzt intern auf ZFS-Snapshots auf. Sie erzeugt und löscht sie selbst – das ist der eine Fall, in dem man sich nicht darum kümmern muss. Details in Proxmox-Cluster ohne Shared Storage.

Zum Ausprobieren

Ein Testsystem, das nach jedem Versuch auf denselben Ausgangsstand zurückgesetzt wird. Dafür sind Snapshots gebaut.

Wofür sie nicht taugen

Als Aufbewahrung über Wochen

Der teuerste Fehler, und zwar aus drei Gründen gleichzeitig:

1. Der Platzbedarf wächst unkontrolliert. Ein Snapshot hält alle Blöcke fest, die seither überschrieben wurden. Bei einer schreibfreudigen VM kann er die Größe des Originals erreichen.
2. Die Leistung leidet. Besonders bei qcow2 mit mehreren Snapshots hintereinander: Jeder Lesezugriff muss sich durch die Kette arbeiten.
3. Der Datenspeicher läuft voll, und dann stehen alle Gäste. Nicht nur der mit dem Snapshot. Bei Thin-Bereitstellung ist ein voller Datenspeicher ein Ausfall der ganzen Umgebung.

Punkt 3 ist der, der wirklich wehtut. Er gehört zu den Fällen, die eine Überwachung mit Benachrichtigung abfangen muss – das Muster dafür steht in Backups überwachen.

Als Aufbewahrungskonzept

Wer verschiedene Stände über Wochen und Monate vorhalten will, braucht eine Sicherung mit Aufbewahrungsregeln, keine Snapshots. Wie so ein Schema aussieht, steht in Backup-Aufbewahrung planen.

Rollback: was dabei verschwindet

Beim Zurückkehren zu einem Snapshot gehen alle Änderungen seit diesem Zeitpunkt verloren. Das ist offensichtlich – und wird trotzdem regelmäßig übersehen, wenn zwischen Snapshot und Rollback jemand anderes am System gearbeitet hat.

Zwei Gewohnheiten helfen:

• Snapshots benennen, nicht durchnummerieren. „vor-update-datenbank“ sagt in drei Wochen etwas, „snapshot1“ nicht.
• Vor dem Rollback kurz prüfen, was seither passiert ist. Bei einem Dienst, den mehrere Leute nutzen, ist ein Rollback ein Eingriff mit Ansage.

Zusammenspiel mit der Sicherung

Für die Sicherung ist die Snapshot-Fähigkeit des Speichers direkt relevant: Sie entscheidet, ob der Gast während der Sicherung weiterlaufen kann.

• Speicher kann Snapshots → die Sicherung läuft im laufenden Betrieb, mit einem kurzen Einfrieren.
• Speicher kann keine Snapshots → der Gast muss angehalten werden, oder die Sicherung arbeitet auf einem sich ändernden Dateisystem.

Das ist ein handfestes Argument für ZFS oder LVM-Thin, und es wiegt schwerer als die Snapshot-Schaltfläche in der Oberfläche. Die Einrichtung selbst: Proxmox Backup Server einrichten.

Die Regeln, kurz

1. Snapshot ist kein Backup. Nie.
2. Vor jeder riskanten Änderung einen, danach löschen.
3. Kein Snapshot älter als ein paar Tage.
4. Mit Arbeitsspeicher nur, wenn der laufende Zustand gebraucht wird.
5. Namen vergeben, die in drei Wochen noch etwas sagen.
6. Freien Platz des Datenspeichers überwachen – ein vergessener Snapshot legt sonst alles still.

Weiter im Cluster

• Proxmox VE im Homelab: der Einstieg – welcher Speicher was kann
• VM oder LXC-Container – Container kennen keinen Arbeitsspeicher-Snapshot
• Proxmox-Cluster ohne Shared Storage – Snapshots als Grundlage der Replikation
• Proxmox Backup Server einrichten – das, was Snapshots nicht sind
• Typische Backup-Fehler – der vergessene Snapshot steht dort in guter Gesellschaft