Here's a scenario that keeps storage admins up at night: ransomware doesn't just lock your production data anymore. The smarter attacks go after your backups too, because if you can't recover, you're far more likely to pay up. And honestly, for years, cloud backup tools didn't do much to stop that — if something had delete permissions, it could delete your backups, full stop. No pushback, no "are you sure," nothing.
Oracle just closed that gap for OCI Block Storage. Backups can now be made genuinely immutable — meaning even someone with the right IAM permissions can't delete or shorten them before a set date. That's a meaningfully different posture than "we have backups" — it's "we have backups that can't be touched, on purpose."
Why This Actually Matters
Most of the ransomware conversations you hear are about prevention — firewalls, endpoint detection, zero trust, all of that. Which is important, sure. But prevention eventually fails somewhere, for someone. The real question is: when it does, can you get your data back? If your backups can be deleted or re-scheduled by anyone with admin access — including an attacker who's already compromised an admin account — the answer is no.
This update isn't flashy. It's not a new dashboard or a slick UI. It's a quiet, structural fix to a real problem: backups that were always assumed safe just because they existed, when in reality they were only as safe as your access controls.
Four Protection Levels, Pick What Fits
Oracle didn't ship one flavor of "protected backup." They gave you four, and they stack from flexible to absolute:
Endurance is the simplest one — just long-term retention. You set an expiration date anywhere from a day to 200 years out, and the backup sticks around until then. You can still rotate encryption keys, still manage it normally. Think of this as "keep it around longer than default," nothing more dramatic.
Governance adds a real safety net: delete prevention. While it's turned on, nobody can manually delete the backup before its retention period is up — but an authorized admin can still turn the protection off if there's a legitimate reason to. It's a guardrail, not a wall.
Compliance is where things get serious. This is Retention Lock, and it's genuinely irreversible once you flip it on. No deleting early, no shortening the retention window, no swapping the encryption key. You can extend the retention period later, but you can never pull it back in. If you've got audit or regulatory requirements breathing down your neck, this is built for that — just don't enable it on a whim, because there's no undo button.
Legal Hold is the nuclear option, in a good way. It overrides whatever retention period was already set and just... holds the backup indefinitely, until someone with the authority explicitly lifts the hold. This is for the situations with no clear end date — active investigations, ongoing litigation, "we genuinely don't know when this will be resolved" scenarios.
The Part Worth Remembering
Heads up — Retention Lock cannot be undone. That's not a minor caveat buried in documentation — it's the whole point of the feature, and it's also the thing most likely to bite someone who enables it without thinking it through first. Get your retention period and key strategy sorted out before you turn it on, not after.
Where to Actually Do This
All of this lives in the Block Storage section of the OCI Console — under Block Volume Backups, Boot Volume Backups, or Volume Group Backups, depending on what you're protecting. Pick the backup, configure the protection level that matches what you're trying to accomplish, and you're done. If you're more of a scripting person, the same controls are exposed through the OCI CLI, the API, and the SDKs, so this isn't a console-only feature bolted on as an afterthought.
The Bottom Line
This isn't a feature you'll ever open the console just to admire. It's the kind of thing you set up once, mostly forget about, and then are extremely grateful for on the one day you actually need it. Ransomware resilience isn't really about stopping every attack — it's about making sure that when one gets through, your recovery path is still there, untouched, waiting for you. Now, at the storage layer, it actually is.