Der 5TB-Schock: Warum ZFS-Snapshots plötzlich den vollen Plattenplatz belegen

Der Moment, in dem alles aufhört, Sinn zu ergeben

Sie denken, Sie verstehen Snapshots. Das denkt jeder: Platte einfrieren, Änderungen nachverfolgen, weitermachen. So war es über Jahre hinweg plattformübergreifend, und deshalb ist der erste Instinkt Panik und nicht Neugier, wenn etwas von 60GB auf mehrere Terabyte explodiert.

Genau dort beginnt diese Geschichte. Eine einfache Erwartung kollidiert mit der Wirklichkeit: Das Anlegen eines Snapshots verdoppelt plötzlich die Speichernutzung. Kein kleiner Overhead, kein Rundungsfehler, sondern Duplikation in voller Breite. „Warum frisst ein 60GB-Snapshot 5TB?“ ist deshalb weniger eine Frage als ein Ausdruck von Unglauben.

Und das Ärgerlichste: Auf den ersten Blick sieht nichts falsch aus. Das UI sagt das eine, ZFS sagt etwas anderes, und irgendwo dazwischen füllt sich Ihr Storage-Pool, ohne dass es jemand merkt.

Das irreführende mentale Modell: „Snapshots speichern nur Änderungen“

Fast jeder kommt mit derselben Annahme: Snapshots sind leichtgewichtig, sie speichern Unterschiede, sie sind von Natur aus effizient. Falsch ist dieser Glaube nicht, nur unvollständig.

Eine Stimme versuchte, die Sache zu den Grundlagen zurückzuführen, und wies darauf hin, dass ZFS-Snapshots „nur die Menge an Plattenplatz verbrauchen, die in der Spalte ‚refer‘ steht“. Das ist die Lehrbuchantwort, sauber, logisch und beruhigend.

Nur prallt diese Erklärung an der Realität ab, wenn sich die Plattennutzung trotzdem verdoppelt. Genau dort wird aus Verwirrung Frustration, weil es sich anfühlt, als würde das System lügen oder im Hintergrund etwas wild Ineffizientes tun.

Spoiler: Es lügt nicht. Es tut genau das, was Sie ihm gesagt haben.

Der versteckte Übeltäter: Thick Provisioning schlägt zurück

Der Wendepunkt kommt von einem trügerisch einfachen Detail: Thin Provisioning war nicht aktiviert. Diese eine Checkbox verändert alles.

Ohne Thin Provisioning verfolgt jeder Snapshot nicht nur Änderungen, er reserviert effektiv die volle Größe der Platte. Und wenn diese Platte 6TB groß ist, wird die Rechnung schnell hässlich. Was wie ein „kleiner“ Snapshot aussieht, verhält sich bei der Speicherzuweisung plötzlich wie ein vollständiger Klon.

Ein Kommentar brachte es klar auf den Punkt: Wenn man Thin Provisioning nicht aktiviert, „belegt jeder Snapshot seine volle Größe statt nur der Unterschiede“. Das ist das fehlende Puzzlestück, und es ist weder ein Bug noch eine Proxmox-Eigenheit, sondern eine Diskrepanz zwischen Konfiguration und Erwartung.

Die zweite Falle: „Es beheben“ passiert nicht sofort

Hier wird es noch frustrierender. Sie finden die Lösung, schalten die Einstellung um und erwarten, dass sich alles wie von Zauberhand korrigiert. Tut es aber nicht.

Thin Provisioning zu aktivieren behebt bestehende Platten nämlich nicht rückwirkend. Ein Nutzer erklärte es unmissverständlich: Es „macht bei bestehenden Platten von selbst gar nichts“. Diese Erkenntnis trifft hart, denn Sie haben die Fehlkonfiguration damit schon in Ihr aktuelles Storage-Layout eingebacken.

Jetzt haben Sie es mit Begriffen wie refreservation, manuellen Konvertierungen und Befehlen zu tun, die sich weit invasiver anfühlen als ein simpler Schalter. Aus einer Snapshot-Frage wird plötzlich ein Storage-Migrationsproblem.

Die Erkenntnisphase: „Oh... das war ich“

In jedem Debugging-Prozess gibt es einen Moment, in dem die Verwirrung in Klarheit umschlägt. In diesem Fall ist er fast hörbar: „Jetzt verstehe ich es.“

Diese Verschiebung ist wichtig, denn das System hat sich erwartbar verhalten, und missverstanden wurde nur, wie seine Teile zusammenspielen. Thick Provisioning plus große Platten plus Snapshots ergibt massiven Speicherverbrauch. Sobald man es sieht, ist es vorhersehbar, und vorher bleibt es unsichtbar.

Genau das macht diese Art von Problem so frustrierend. Im Nachhinein ist es nicht komplex, es liegt nur hinter Annahmen verborgen, die sich universell anfühlen und es nicht sind.

Die größere Kluft: ZFS-Puristen und UI-First-Nutzer

Die ganze Situation legt eine tiefere Kluft darin offen, wie Menschen an Systeme wie Proxmox herangehen.

Auf der einen Seite stehen die ZFS-nativen Denker. Sie leben in zfs list, verstehen refer im Unterschied zu used und behandeln das Proxmox-UI als Komfortschicht. Für sie ist dieses Problem fast offensichtlich, denn natürlich beeinflussen Provisioning-Einstellungen das Snapshot-Verhalten.

Auf der anderen Seite stehen Nutzer, die der Abstraktion vertrauen. Sie erwarten, dass sich Snapshots so verhalten wie überall sonst, und verlassen sich darauf, dass das UI die Realität widerspiegelt statt sie neu zu interpretieren. Tut es das nicht, fühlt es sich kaputt an, auch wenn es das nicht ist.

Keine Seite liegt falsch, sie sprechen nur leicht unterschiedliche Sprachen.

Was das tatsächlich lehrt

Wenn es hier eine Erkenntnis gibt, dann diese: Storage-Systeme verzeihen keine Annahmen, ZFS am allerwenigsten.

Thin und Thick Provisioning klingen nach einem Nebendetail, bis eines davon unauffällig Ihre Plattennutzung verdoppelt. Snapshots klingen leichtgewichtig, bis sie das volle Gewicht Ihrer Konfiguration erben. Und Schalter, die harmlos aussehen, können darüber bestimmen, wie im Hintergrund Terabytes zugewiesen werden.

Die Lösung besteht darin, das Modell dahinter zu verstehen, und nicht bloß darin, eine Einstellung zu aktivieren. Sobald man es versteht, wirkt das Verhalten unausweichlich statt zufällig. Und das ist vielleicht der frustrierendste Teil von allem.