„Ihre Snapshots sind nicht kaputt—Ihre Annahmen sind es“: Der 5TB-Schock, der eine versteckte ZFS-Falle offenlegt

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, weshalb der erste Instinkt, wenn etwas von 60GB auf mehrere Terabyte explodiert, nicht Neugier ist—sondern Panik.

Genau dort beginnt diese Geschichte. Eine einfache Erwartung kollidiert mit einer brutalen Realität: Das Anlegen eines Snapshots verdoppelt plötzlich die Speichernutzung. Nicht ein bisschen Overhead. Kein Rundungsfehler. Volle Duplikations-Vibes. „Warum frisst ein 60GB-Snapshot 5TB?“ ist nicht nur eine Frage—es ist Unglauben.

Und der schlimmste Teil? 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 still und leise.

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

Hier ist die Annahme, mit der fast jeder an die Sache herangeht: Snapshots sind leichtgewichtig. Sie speichern Unterschiede. Sie sind von Natur aus effizient. Dieser Glaube ist nicht falsch—er ist 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. Beruhigend.

Aber diese Erklärung prallt an der Realität ab, wenn sich die Plattennutzung trotzdem verdoppelt. Genau dort wird aus Verwirrung Frustration. Denn jetzt fühlt es sich an, als würde das System lügen—oder schlimmer, 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 plötzlich wie ein vollständiger Klon in Bezug auf die Speicherzuweisung.

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. Kein Bug. Keine Proxmox-Eigenheit. Nur 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.

Denn das Aktivieren von Thin Provisioning behebt bestehende Platten nicht rückwirkend. Ein Nutzer erklärte es unmissverständlich: Es „macht bei bestehenden Platten von selbst gar nichts“. Diese Erkenntnis trifft hart. Sie haben nicht nur etwas falsch konfiguriert—Sie haben diese Fehlkonfiguration 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. Und plötzlich wird aus einer Snapshot-Frage ein Storage-Migrationsproblem.

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

Es gibt in jedem Debugging-Prozess 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 nicht unerwartet verhalten—Sie haben nur missverstanden, wie seine Teile zusammenspielen. Thick Provisioning plus große Platten plus Snapshots ergibt massiven Speicherverbrauch. Vorhersehbar, sobald man es sieht. Unsichtbar, bis man es tut.

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

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

Diese ganze Situation legt still eine tiefere Kluft offen, wie Menschen an Systeme wie Proxmox herangehen.

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

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

Keine Seite liegt falsch. Aber sie sprechen leicht unterschiedliche Sprachen.

Was das tatsächlich lehrt

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

Thin vs. Thick Provisioning klingt nach einem Nebendetail, bis es still Ihre Plattennutzung verdoppelt. Snapshots klingen leichtgewichtig, bis sie das volle Gewicht Ihrer Konfiguration erben. Und Schalter, die harmlos aussehen, können bestimmen, wie im Hintergrund Terabytes zugewiesen werden.

Die Lösung ist nicht nur, eine Einstellung zu aktivieren. Es ist, das Modell dahinter zu verstehen. Denn sobald man das tut, hört das Verhalten auf, sich zufällig anzufühlen—und beginnt, sich unausweichlich anzufühlen.

Und das ist vielleicht der frustrierendste Teil von allem.