Why Immutable Storage Is Important for Your MSP
If you're an MSP, backups aren't just about "having copies." They're about having recoverable, trusted copies—even when a bad actor is already inside the environment.
That's where immutable storage matters. In plain terms: immutable backups are written in a way that they can't be altered or deleted for a set period of time—even if an attacker (or a compromised admin account) has credentials.
In this post:
- Why immutable storage is now a baseline requirement (not a "nice-to-have")
- Why "immutable" isn't always truly enabled or truly protected with every provider
- Why immutability set to "days" (or 60–90 days) can still leave you exposed—and why we push for one year
1) Why immutable storage matters (the threat changed)
A lot of MSPs still think about backups the way we did years ago: something breaks, something encrypts, you restore the most recent clean point.
The problem is that modern attacks don't always announce themselves immediately—and they don't follow a predictable timeline. Some attacks move fast and do damage in days. Others linger for months while an attacker quietly learns the environment, identifies valuable systems, and looks for ways to sabotage recovery options.
That's why immutable storage matters: you have to be ready for both.
⚡ Fast Attacks
If an attack is quick, immutability helps ensure you still have recent restore points you can trust.
🕒 Lingering Attacks
If an attack lingers, immutability helps protect older restore points so you can roll back to a clean point-in-time—before the compromise had time to spread.
In other words: if your backups can be tampered with—or if your safe rollback window is too short—an attacker can corner you into the one outcome you're trying to avoid.
2) "Immutable" isn't always truly protected (admin credentials are the test)
Here's the hard truth: if admin-level credentials can delete your backups, then an attacker who compromises admin credentials can delete your backups too.
That's why "immutable" can't just be a checkbox or a marketing term. You need to confirm that your immutable backups cannot be deleted or altered by anyone during the immutable retention window—including administrators.
So the real question isn't just "Do we have backups?" It's:
If an attacker gets admin credentials, can they delete or override what's supposedly immutable?
If the answer is anything other than a clear "no," you don't have true immutability—you have a vulnerability.
3) Why immutable retention should be set to one year (not days)
Even when a provider supports immutability, the next question is how long those backups are protected.
Some environments end up with immutable retention set to days by default. Others are set to 60–90 days because it "sounds reasonable." The issue is simple: attacks don't follow a convenient timeline. Some hit fast. Others linger long enough that short retention windows can leave you without a clean point-in-time when you finally discover what happened.
That's why we push a clear standard:
Keep one year of immutable retention.
A full year gives you the runway to recover from the messy reality of modern incidents—whether you need to restore something that was quietly compromised weeks ago, or you discover the damage long after it started.
⚠️ Important Distinction
Some providers may offer long retention (keeping versions), but that's not the same as long immutability (preventing deletion/alteration). You want both.
Conclusion: Don't just "have backups"—make sure you can trust them
Immutable storage is how you protect the thing that ransomware is increasingly designed to destroy: your ability to restore.
So here's the action we recommend this week:
Action Items
- Verify "immutable" is truly immutable (not overridable—even by admin credentials).
- Confirm your immutable retention is one year (not "days," not 60–90 days).
- Ask the hard scenario questions (deleted accounts, removed volumes, compromised credentials).
