Your Snapshots Aren't Broken, Your Assumptions Are: The 5TB Shock That Exposes a Hidden ZFS Trap

# “Your Snapshots Aren’t Broken—Your Assumptions Are”: The 5TB Shock That Exposes a Hidden ZFS Trap ## The Moment Everything Stops Making Sense You think you understand snapshots. Everyone does. Freeze the disk, track the changes, move on. It’s been that way for years across platforms, so when something explodes from 60GB to multiple terabytes, your first instinct isn’t curiosity—it’s panic. That’s exactly where this story starts. A simple expectation collides with a brutal reality: creating a snapshot suddenly doubles disk usage. Not a little overhead. Not a rounding error. Full-on duplication vibes. “Why is a 60GB snapshot eating 5TB?” isn’t just a question—it’s disbelief. And the worst part? At first glance, nothing looks wrong. The UI says one thing. ZFS says another. And somewhere in between, your storage pool is quietly filling up. ## The Misleading Mental Model: “Snapshots Only Store Changes” Here’s the assumption almost everyone brings into this: snapshots are lightweight. They store differences. They’re efficient by design. That belief isn’t wrong—it’s just incomplete. One voice tried to steer things back to basics, pointing out that ZFS snapshots “only consume the amount of disk space in the ‘refer’ column.” That’s the textbook answer. Clean. Logical. Comforting. But that explanation crashes into reality when your disk usage doubles anyway. That’s where confusion turns into frustration. Because now it feels like the system is lying to you—or worse, doing something wildly inefficient behind the scenes. Spoiler: it’s not lying. It’s doing exactly what you told it to do. ## The Hidden Culprit: Thick Provisioning Bites Back The turning point comes from a deceptively simple detail: thin provisioning wasn’t enabled. That one checkbox changes everything. Without thin provisioning, every snapshot isn’t just tracking changes—it’s effectively reserving the full size of the disk. And when that disk is 6TB, the math gets ugly fast. What looks like a “small” snapshot suddenly behaves like a full clone in terms of space allocation. One comment nailed it in plain terms: if you don’t enable thin provisioning, “every snapshot will take up its full size rather than the differences.” That’s the missing piece. Not a bug. Not a Proxmox quirk. Just a configuration mismatch between expectation and reality. ## The Second Trap: “Fixing It” Isn’t Instant Here’s where things get even more frustrating. You find the solution, flip the setting, and expect everything to magically correct itself. But it doesn’t. Because enabling thin provisioning doesn’t retroactively fix existing disks. One user explained it clearly: it “won’t do anything on its own for existing disks.” That realization hits hard. You didn’t just misconfigure something—you baked that misconfiguration into your current storage layout. Now you’re dealing with terms like `refreservation`, manual conversions, and commands that feel way more invasive than a simple toggle. And suddenly, what started as a snapshot question turns into a storage migration problem. ## The Realization Phase: “Oh… It Was Me” There’s a moment in every debugging process where the confusion snaps into clarity. In this case, it’s almost audible: “I get it now.” That shift matters. Because the system didn’t behave unexpectedly—you just misunderstood how its pieces interact. Thick provisioning plus large disks plus snapshots equals massive space consumption. It’s predictable once you see it. Invisible until you do. And that’s what makes this kind of issue so frustrating. It’s not complex in hindsight. It’s just buried behind assumptions that feel universal but aren’t. ## The Bigger Divide: ZFS Purists vs. UI-First Users This whole situation quietly exposes a deeper divide in how people approach systems like Proxmox. On one side, you’ve got the ZFS-native thinkers. They live in `zfs list`, understand `refer` vs. `used`, and treat the Proxmox UI as a convenience layer. For them, this issue is almost obvious. Of course provisioning settings affect snapshot behavior. On the other side, there are users who trust the abstraction. They expect snapshots to behave like they do everywhere else. They rely on the UI to reflect reality, not reinterpret it. And when it doesn’t, it feels like something is broken—even when it isn’t. Neither side is wrong. But they’re speaking slightly different languages. ## What This Actually Teaches You If there’s one takeaway here, it’s this: storage systems don’t forgive assumptions. Especially not ZFS. Thin vs. thick provisioning sounds like a minor detail until it quietly doubles your disk usage. Snapshots sound lightweight until they inherit the full weight of your configuration. And toggles that look harmless can define how terabytes get allocated behind the scenes. The fix isn’t just enabling a setting. It’s understanding the model underneath it. Because once you do, the behavior stops feeling random—and starts feeling inevitable. And maybe that’s the most frustrating part of all.