Immutable Backups Aren't Really Immutable: The Uncomfortable Truth No One Wants to Admit

# “Immutable Backups Aren’t Really Immutable”: The Uncomfortable Truth No One Wants to Admit ## The Expectation: “We Had It Perfect Before—Why Is This Missing?” When you come from a setup that just works, anything less feels broken. That’s the mood here. Moving from VMware with Veeam into Proxmox Backup Server isn’t just a platform switch—it’s a shift in expectations. And the biggest shock? Immutable backups don’t seem to exist in the same way. That’s not a small feature. It’s peace of mind. The idea that once a backup is written, no one—not even an admin—can touch it. Losing that feels like losing a safety net. The question isn’t just technical, it’s emotional: “What are people doing instead?” Because once you’ve had true immutability, going backwards feels dangerous. ## The First Answer: “You Don’t Need Immutability—You Need Permissions” The first wave of responses pushes back on the premise itself. Not aggressively, but firmly. You can achieve the same outcome, they argue, just by controlling permissions. One explanation is straightforward: give Proxmox Backup Server write-only access. It can create backups, but not modify or delete them. That sounds close enough to immutability, at least on paper. Others expand on that idea—separating control planes, isolating systems, making sure the entity that writes backups isn’t the one that can destroy them. It’s a different model, but it aims for the same end: protection against accidental or malicious deletion. Still, there’s a lingering doubt. Because “close enough” isn’t the same as guaranteed. ## The Skeptics: “That’s Not Real Immutability” Then the tone sharpens. Some voices argue that what’s being described isn’t immutability at all—it’s just access control dressed up as something stronger. One comment cuts right to it: immutability is “just a lock of one user being able to make changes… it’s not magic.” That perspective reframes everything. Whether it’s Proxmox, S3, or Ceph, the underlying mechanism is the same: permissions. You’re restricting actions, not making data untouchable. And if permissions can be changed—or bypassed through exploits, root access, or bugs—then nothing is truly immutable. It’s a harsh take. But it’s hard to ignore once you hear it. ## The Cloud Argument: “S3 Object Lock Solves This” On the other side, there’s a more confident stance: object storage with immutability features—like S3 Object Lock—gets you as close as possible. One user insists that once object lock is enabled, “no user level can delete” the data. That’s the gold standard many people are chasing. A system where even admins are locked out during the retention period. And it works. Mostly. But even here, the cracks show. Someone points out the obvious: cloud providers still control the underlying infrastructure. Accidental deletions, exploits, or internal failures aren’t impossible. So now the question shifts again—not “is it immutable?” but “who do you trust more?” ## The Pragmatists: “Just Keep Using Veeam” Some people don’t bother with philosophical debates. They look at the gap and make a simple call: stick with what already solves the problem. Veeam still works with Proxmox. It still supports object storage. It still delivers the immutability guarantees users are used to. It’s not elegant. It doesn’t fully embrace the Proxmox ecosystem. But it works. And sometimes, that’s enough. ## The Workaround Builders: “Recreate Immutability Through Architecture” Others take a more creative route. If Proxmox Backup Server doesn’t offer immutability directly, you can build it indirectly. Use pull sync jobs. Separate backup servers. Ensure the system storing backups isn’t the one creating them. Add layers. Add distance. Add friction between creation and deletion. It’s not a single feature—it’s a design pattern. And in some ways, it’s more flexible. You’re not relying on one vendor’s definition of immutability. You’re constructing your own version of it, tailored to your risk tolerance. But it’s also more complex. And complexity has its own risks. ## The Uncomfortable Truth: Nothing Is Truly Immutable If there’s one thread connecting all these perspectives, it’s this: “immutable” is more of a promise than a guarantee. Even the strongest systems rely on rules, permissions, and assumptions about who can do what. Break those assumptions—through bugs, exploits, or human error—and the illusion cracks. That doesn’t mean immutability is useless. Far from it. It raises the bar. It prevents common failure modes. It protects against ransomware, accidental deletion, and misconfigured scripts. But it’s not absolute. And maybe that’s the hardest part to accept. ## So What Are People Actually Doing? In practice, people are mixing approaches: - Using Proxmox Backup Server with strict permissions - Adding offsite copies through sync jobs - Leveraging S3-compatible storage with object lock - Or simply sticking with Veeam for now Not because one solution is perfect, but because each covers a different risk. That’s the real shift here. Moving from a single “immutable” checkbox to a layered strategy. And once you see it that way, the question changes. It’s no longer “where is immutability?” It’s “how many barriers do I need before I feel safe?” Because in the end, that’s what immutability was always trying to give you.