SAN-Snapshots in Proxmox: eine Kette, kein Storage-Snapshot

/01Was „SAN-Snapshot" bei Proxmox eigentlich bedeutet

Thick-provisioniertes Shared LVM auf einem klassischen SAN — angebunden per Fibre-Channel oder iSCSI — konnte von Haus aus keine VM-Snapshots: anders als VMFS, wo ein Snapshot seit jeher eine Zeile im Kontextmenü ist. Native LVM-Snapshots sind auf gemeinsamem Speicher unbrauchbar, weil sie den gesamten Schreibzugriff auf die Volume Group blockieren, solange sie aktiv sind. Thin Provisioning per LVM-thin scheidet auf geteiltem Storage ebenso aus — mehrere Knoten, die gleichzeitig in denselben Metadatenbereich schreiben, sind ein Rezept für Datenverlust, nicht für Snapshots. Das war jahrelang die Lücke, die VMware-Verteidiger zu Recht benannten — obwohl Shared LVM in allem anderen bereits mithielt, Live Migration eingeschlossen, weil die Disk ohnehin auf dem gemeinsamen LUN liegt.

Mit Proxmox VE 9 (2025) kam eine Antwort, aber keine, die eins zu eins auf VMFS abbildet. „Snapshots as volume chains" legt bei jedem Snapshot ein neues, komplett belegtes Logical Volume an, das ein QCOW2-Overlay trägt und das vorherige Image als Backing-File referenziert. Das ist kein Storage-Snapshot im Sinn eines Copy-on-Write-Dateisystems, das die Array-Firmware oder der LVM-Kernel-Treiber selbst beherrscht — es ist eine Kette, die vollständig in QEMU verwaltet wird, oberhalb des Blockgeräts. Wer aus der VMware-Welt kommt, kennt das Prinzip: Es ähnelt den Delta-Disks, die vSphere vor der Konsolidierung anlegt, nur dass Proxmox die Kette dauerhaft stehen lässt, statt sie zeitnah zu verschmelzen.

Dieser Artikel behandelt ausschließlich diesen einen Mechanismus in der Tiefe: Aufbau, Einrichtung, Speicherbedarf, gemessene Leistung und Grenzen. Die vollständige Landschaft der Alternativen — SAN-Hardware-Snapshots, Proxmox Backup Server, herstellerspezifische Storage-Plugins — ordnet der Grundlagenartikel zur FC-SAN-Migration im Überblick ein; hier geht es um den einen Weg, der am häufigsten missverstanden wird.

/02Die Mechanik: eine Kette aus QCOW2-Overlays

Technisch passiert Folgendes, wenn eine VM-Disk auf shared LVM einen Snapshot bekommt: Proxmox legt ein neues Logical Volume in voller Größe des ursprünglichen Disks an, formatiert es als QCOW2-Image und trägt als Backing-File das vorherige Image ein — beim ersten Snapshot die rohe Basisplatte, danach jeweils die vorherige Kettenschicht. Schreibzugriffe der laufenden VM landen ausschließlich in der obersten Schicht. Lesezugriffe wandern die Kette hinunter, bis der angeforderte Block gefunden ist — bei einem frisch gebooteten System liegt das meiste noch in der Basis, bei einer VM, die seit dem Snapshot intensiv beschrieben wurde, kann das mehrere Schichten dauern.

Basis-LV (Original-Disk)          Snapshot-LV 1                Snapshot-LV 2 (aktiv)
┌─────────────────────┐   ┌─────────────────────┐   ┌─────────────────────┐
│ raw oder qcow2       │◄──┤ qcow2, backing_file  │◄──┤ qcow2, backing_file  │
│ volle Kapazität      │   │ = Basis-LV            │   │ = Snapshot-LV 1       │
│                       │   │ volle Kapazität       │   │ volle Kapazität       │
└─────────────────────┘   └─────────────────────┘   └─────────────────────┘
        Lesen: nur wenn                                      Schreiben: hier,
        weiter oben nicht                                    und nur hier
        gefunden

Weil mehrere Proxmox-Knoten dasselbe LUN sehen, braucht das Anlegen und Löschen von Schichten eine clusterweite Sperre: Genau ein Knoten aktualisiert zu einem Zeitpunkt die LVM-Metadaten der Volume Group, die anderen fragen den Zustand ab, statt selbst zu schreiben. Das ist derselbe Mechanismus, den LVM-Storage im geteilten Betrieb ohnehin nutzt, wenn es als shared 1 markiert ist — die Volume-Kette nutzt ihn mit, erzeugt aber häufiger Metadatenänderungen als ein reiner Disk-Anlage-Vorgang, weil jeder Snapshot eine neue LV-Anlage bedeutet.

Eine Voraussetzung nennt die Proxmox-Dokumentation ausdrücklich: Der zugrunde liegende Storage muss Thin Provisioning und Discard unterstützen, damit sich Kapazität nach dem Löschen einer Schicht überhaupt zurückgewinnen lässt. Ohne diese Fähigkeit auf Array-Seite bleibt jede angelegte Schicht dauerhaft belegt, selbst nachdem der zugehörige Snapshot längst entfernt wurde.

/03Einrichtung: das Flag, die Voraussetzungen, die Befehle

Auf einem bereits eingerichteten Shared-LVM-Storage — LUN über Multipath sauber eingebunden, thick, mit dem Flag shared 1, wie im Grundlagenartikel zur FC-SAN-Migration beschrieben — schaltet ein einziger zusätzlicher Parameter die Volume-Kette scharf:

# /etc/pve/storage.cfg
lvm: san01
    vgname shared-san
    shared 1
    content images,rootdir
    snapshot-as-volume-chain 1

Der Parameter wirkt nur auf neu angelegte Volumes. Bereits bestehende Disks im rohen Format (raw) unterstützen keine Snapshots — sie müssen zunächst in eine qcow2-basierte VM-Disk konvertiert werden, sonst quittiert Proxmox den Snapshot-Versuch mit einem Fehler. Das ist in der Praxis der häufigste erste Stolperstein: Wer eine bestehende Umgebung nachrüstet, konvertiert zunächst die Disk, nicht nur den Storage.

# Vorbereitung pruefen: Storage bereit, Voraussetzungen erfuellt?
pvesm status --storage san01

# Snapshot anlegen (Aequivalent zum GUI-Knopf)
qm snapshot 140 vor-kernel-update --description "vor Kernel-Update 6.14"

# Kette der VM einsehen
qm listsnapshot 140

# Snapshot wieder entfernen
qm delsnapshot 140 vor-kernel-update

Weil die Volume-Kette unterhalb von LVM ansetzt, ist ihr die Transportart des LUN gleichgültig — ob das darunterliegende Blockgerät über Fibre-Channel, iSCSI oder auf neueren Arrays über NVMe-oF eingebunden ist, ändert an der Kettenmechanik nichts. Was sich ändert, ist die Latenz und der Durchsatz, mit denen jede zusätzliche Kettenschicht bezahlt wird — dazu mehr im Abschnitt zur Leistung.

/04Was ein Snapshot an Speicher kostet

Der Punkt, der die meisten Administratoren überrascht: Jede Kettenschicht ist thick-provisioniert und beansprucht auf LVM-Ebene sofort die volle Kapazität der Original-Disk — nicht nur die geänderten Blöcke. Was auf dem Array durch Thin Provisioning am Ende tatsächlich belegt wird, kann kleiner sein, aber die LVM-Reservierung selbst rechnet immer mit der vollen Größe. Bei einer VM mit häufigen Snapshots wächst der reservierte Bedarf entsprechend schnell.

Blockbridge rechnet dazu ein Beispiel vor: Für ein 1-TiB-Disk-Volume mit 24 stündlichen Snapshots — ein realistischer Rhythmus vor einer Reihe riskanter Änderungen — nennt die Quelle einen Kapazitätsbedarf von rund 27,5 TiB auf dem LUN, wenn man QCOW2-Metadaten und einen Fragmentierungspuffer von etwa 10 Prozent einrechnet. Das ist keine Randnotiz: Wer die Volume-Kette einführt, ohne diese Rechnung vorher zu machen, füllt sein SAN schneller als erwartet.

Für die Praxis heißt das: Ein SAN-LUN, das für die Volume-Kette vorgesehen ist, braucht deutlich mehr Reserve als ein LUN für reine Disk-Kapazität — und die Reserve hängt direkt an der Zahl und Lebensdauer der Snapshots, die Sie tatsächlich vorhalten. Wer stündliche Snapshots über Tage laufen lässt, statt sie nach dem Update wieder zu entfernen, multipliziert diesen Bedarf ungebremst weiter.

/05Die Performance-Zahlen im Detail

Der Grundlagenartikel zur FC-SAN-Migration nennt bereits die Bandbreite „30 bis 90 Prozent" für den Performance-Verlust der Volume-Kette gegenüber rohen Volumes. Das ist korrekt, aber grob — die Quelle dahinter, unabhängige FIO-Messungen von Blockbridge, differenziert genauer, und die Differenzierung ist die Information, die für eine Kapazitätsplanung zählt.

Ohne einen einzigen Snapshot — reines QCOW2 auf thick LVM gegen rohe LVM-Volumes gemessen — fiel bei Disks unter 256 GiB die Bandbreite um 60 Prozent und die IOPS-Zahl um 30 Prozent. Bei größeren Disks, deren QCOW2-Metadaten nicht mehr vollständig im Cache liegen, sackte die Leistung bei wahlfreien Zugriffsmustern um bis zu 90 Prozent ab. Kommen Snapshots in der Kette hinzu, verschlechtert sich das Bild weiter: Jede zusätzliche Schicht erhöht die Wahrscheinlichkeit, dass ein Lesezugriff mehrere Ebenen durchqueren muss, bevor er den angeforderten Block findet — die sogenannte I/O-Amplifikation wächst mit der Kettenlänge.

Zur Ehrlichkeit gehört auch die Lücke in der Quelle: Blockbridge nennt „Standard-FIO-Tests" als Methode, veröffentlicht aber weder Warteschlangentiefe noch exakte Hardware- oder SAN-Konfiguration der Messung, und die Zahl der Snapshots in der „mit Kette"-Messung bleibt offen. Die Größenordnung ist damit belastbar belegt, ein exakter Wert für Ihre eigene Umgebung ist es nicht — der hängt am Array-Controller, an der Netzwerklatenz zum LUN und an der Kettenlänge, mit der Sie tatsächlich arbeiten. Was sich unabhängig davon aus der Proxmox-Entwicklung bestätigen lässt: Ein Proxmox-Entwickler (Nutzername Spirit) beschreibt im Forum, dass der Mechanismus bis etwa 256 GB pro Volume zuverlässig funktioniert; darüber wird der L2-Metadaten-Cache von QEMU zum Engpass und muss über die Cluster-Konfiguration angehoben werden — mit optimierten Einstellungen rechnet er mit rund 4 MB Cache-Speicher je 1 TB Image.

/06Wo es zusätzlich hakt

Fünf Punkte, die vor dem produktiven Einsatz auf den Tisch gehören — nicht danach.

Kein Journaling, kein Ersatz für Backup

QCOW2 serialisiert Metadaten- und Datenschreibvorgänge nicht wie ein Journaling-Dateisystem. Neu angelegte Logical Volumes tragen zudem keine Garantie für eine Null-Initialisierung — bei einem Stromausfall während einer aktiven Kettenschicht besteht das Risiko, dass alte, „fremde" Daten aus dem vorherigen Inhalt des LV sichtbar werden. Ein Snapshot ist ein Rücksprungpunkt, kein Backup; wer beides braucht, braucht weiterhin eine eigenständige Sicherung.

Der oberste Snapshot bleibt bei laufender VM stehen

In Proxmox VE 9.2 lässt sich die oberste Schicht einer Kette nicht entfernen, solange die VM läuft — die Roadmap führt „Online-Entfernung des obersten Snapshots" ausdrücklich als offenen Punkt. Praktisch bedeutet das: Ein Wartungsfenster für das Aufräumen alter Snapshots einzuplanen ist derzeit keine Vorsichtsmaßnahme, sondern Pflicht.

Speicher wird nicht automatisch frei

Wie in Abschnitt 4 beschrieben, braucht die Freigabe von Kapazität nach dem Löschen einer Schicht ein explizites Zeroing. Wer das Safe-Remove-Verhalten nicht kennt, wundert sich über ein SAN, das trotz gelöschter Snapshots nicht schrumpft.

Unbegrenztes Cache-Wachstum als Angriffsfläche

Blockbridge weist im Forum auf ein Risiko hin, das über reine Performance hinausgeht: Wächst der QEMU-Metadaten-Cache mit jeder zusätzlichen Kettenschicht mit, lässt sich durch gezieltes, häufiges Anlegen von Snapshots Speicher auf dem Hypervisor erschöpfen — ein möglicher Denial-of-Service-Vektor, den die Proxmox-Entwicklung mit angehobenen, aber weiterhin konfigurierbaren Cache-Obergrenzen begrenzt.

Die Freigabe selbst ist eine Ansage, keine Formsache

Sowohl die Herstellerdokumentation von Blockbridge als auch ein Proxmox-Mitarbeiter im Forum (Nutzername bbgeek17) formulieren es unmissverständlich: „This is currently a technology preview, so be considerate" — der Hinweis „nicht für den Produktiveinsatz empfohlen" steht nicht aus Vorsicht da, sondern weil die Entwicklung selbst noch aktiv Verhalten ändert.

/07Der Stand in Roadmap und Forum

Die offizielle Proxmox-Roadmap formuliert das Ziel für die Volume-Kette so: „Bring 'snapshots as volume chains' (tech preview since Proxmox VE 9.0) out of tech preview on LVM-thick, Directory, NFS, and CIFS storages, including support for online removal of the top-most snapshot." Zwei Dinge stehen damit fest: Die Funktion war seit Proxmox VE 9.0 (2025) Technologie-Vorschau und ist es mit Stand Version 9.2 (Mai 2026) weiterhin — ein konkretes Datum für die Freigabe nennt die Roadmap nicht, historisch fallen solche Übergänge eher mit Major-Releases zusammen als mit Zwischenversionen.

Im Forum ist die Entwicklung sichtbar aktiv, nicht eingefroren: Der bereits erwähnte Proxmox-Entwickler Spirit hat eine auf blkdiscard gestützte Optimierung der Safe-Remove-Routine beigesteuert, die seit dem Paket pve-storage 9.0.14 ausgeliefert wird, und die Standard-Obergrenzen für den QEMU-Cache angehoben. Proxmox VE 9.1 (November 2025) hat außerdem eine frühere Einschränkung für Windows-VMs mit virtuellem TPM behoben, indem der TPM-Zustand ebenfalls im QCOW2-Format abgelegt werden kann; seit Version 9.2 funktionieren dadurch auch Live-Snapshots solcher VMs.

Die ehrliche Einordnung: Wer die Volume-Kette heute einsetzt, testet mit der Community mit — nicht gegen einen stillstehenden Stand, sondern gegen eine Funktion, die sich zwischen zwei Punktversionen bereits spürbar verändert hat. Das spricht nicht gegen den Test auf nicht-kritischen Workloads, aber gegen einen Rollout, der auf einen fixen Funktionsumfang vertraut.

/08Die Alternativen kurz eingeordnet

Die Volume-Kette ist eine von mehreren Antworten auf dieselbe Lücke, und für die meisten KMU-Umgebungen ist sie nicht zwangsläufig die erste Wahl. SAN-Hardware-Snapshots — bei praktisch jedem Enterprise-Array vorhanden — laufen ohne QCOW2-Overhead direkt im Controller, sind dafür aber LUN-granular statt VM-granular aus der Proxmox-GUI heraus bedienbar. Der Proxmox Backup Server deckt den häufigsten eigentlichen Bedarf ab: einen schnellen Rücksprungpunkt vor einem riskanten Update, inkrementell und ohne die Schreiblast, die eine wachsende Kette erzeugt.

Wer nicht an ein bestehendes SAN gebunden ist, umgeht die ganze Fragestellung: Ceph und ZFS bringen Snapshots als native Funktion ihres jeweiligen Speicherformats mit, ohne QCOW2-Zwischenschicht und ohne die hier beschriebenen Kapazitäts- und Leistungsrechnungen. Das ist kein Ersatz für ein bestehendes FC-SAN, das noch Jahre Restwert hat, aber ein Grund, die Frage „SAN behalten oder umbauen" bei einer ohnehin anstehenden Hardware-Erneuerung neu zu stellen. Die vollständige Gegenüberstellung aller vier Wege — SAN-Hardware, Volume-Kette, PBS, Storage-Plugins — mit einer Vergleichstabelle steht im Grundlagenartikel zur FC-SAN-Migration.

/09Wann sich die Volume-Kette lohnt — und wann nicht

Die Volume-Kette ist ein Werkzeug mit einem engen, aber echten Einsatzbereich — kein Universalersatz für den VMFS-Snapshot, an den VMware-Umsteiger gewöhnt sind.

Dafür spricht

• Kein Storage-Plugin und keine Array-Snapshot-Lizenz vorhanden: Wenn das SAN selbst keine performanten Snapshots anbietet oder deren Lizenz zusätzlich kostet, ist die Volume-Kette der einzige Weg zu einem VM-granularen Rücksprungpunkt direkt aus der Proxmox-GUI.
• Kleine, klar abgegrenzte Testfenster: Ein Snapshot vor einem Update, der Stunden später wieder entfernt wird — nicht Tage oder Wochen —, hält den Speicherbedarf und den Performance-Verlust überschaubar.
• Nicht-kritische oder Testworkloads: Gerade weil die Funktion Technologie-Vorschau ist, passt sie zuerst auf Systeme, deren kurzzeitiger Leistungsverlust oder eine ausbleibende Freigabe verkraftbar ist.

Dagegen spricht

• Leistungskritische Workloads mit hoher Schreiblast: Datenbanken oder Anwendungen mit engem IOPS-Budget spüren 30 bis 90 Prozent Verlust sofort — hier tragen SAN-Hardware-Snapshots oder ein Verzicht auf dauerhafte Ketten deutlich besser.
• Lang laufende oder viele parallele Snapshots: Die Speicherrechnung aus Abschnitt 4 wächst linear mit jeder Schicht — wer Snapshots als dauerhaften Zustand statt als kurzes Zeitfenster nutzt, braucht ein SAN, das diese Reserve auch hat.
• Harte Anforderungen an Betriebssicherheit: Wo eine Vorgabe — Kunde, Versicherer, interne Richtlinie — den Verzicht auf Technologie-Vorschau-Funktionen im Produktivbetrieb verlangt, ist die Antwort damit bereits gegeben.

Unsere Praxis-Linie deckt sich mit der aus dem Grundlagenartikel: Produktivstart mit SAN-Hardware-Snapshots und Proxmox Backup Server, die Volume-Kette parallel auf unkritischen Systemen erproben und erst dann in die Produktivfläche übernehmen, wenn sie den Vorschau-Status verlässt oder Ihre eigenen Tests die gemessenen Werte für Ihr Array bestätigen.

/10Häufige Fragen