Object Lock and Versioning Explained: How Stornox Protects Backups From Ransomware

Ransomware doesn't discriminate. It targets backup repositories with the same aggression as primary systems. When backups are compromised, recovery becomes a negotiation rather than a straightforward procedure.
Cloud storage with proper immutability controls isn't optional anymore; it's the line between a recoverable incident and a catastrophic one. Stornox was built with that reality in mind.

Why Ransomware Targets Your Backups First

Modern ransomware operators understand infrastructure. Before triggering encryption, many strains spend days or weeks in reconnaissance, specifically identifying and targeting backup systems. Destroying recovery paths maximizes their leverage. If you can restore from backup, the ransom loses its power.

This is why the conversation around cloud storage has moved beyond capacity and cost to something more fundamental, which is write protection at the infrastructure level.

What Object Lock Actually Does in Cloud Storage

Object Lock is a storage-layer control that prevents objects from being deleted or overwritten for a defined period. It operates independently of application-level permissions, IAM policies, or administrative credentials, which is the entire point.

Think of it as physical writing protection on a tape, but enforced by the storage platform itself. Even a compromised account with full administrative privileges cannot delete a locked object before its retention period expires. There's no override key held by the tenant. That immutability is real, not cosmetic.

Stornox adds another layer of protection through its four step data architecture. Data is first encrypted using AES 256 GCM with client controlled keys. It is then fragmented into encrypted chunks and replicated using Reed Solomon error correction for data resilience. These shards are distributed across geo fenced nodes in India, ensuring that no single node stores the complete file.

Stornox implements Object Lock through an S3-compatible API, so it integrates natively with backup platforms such as Veeam, Nakivo, Synology, QNAP, Rclone, AWS CLI, Rubrik, and Commvault without custom connectors. A backup job that writes to a Stornox bucket with Object Lock enabled creates an immutable restore point automatically.

Object Lock also plays an important role in meeting regulatory requirements. Cloud storage that offers verified immutability gives compliance teams documentary evidence, not just assertions.

Versioning: The Layer Beneath the Lock

Versioning keeps every iteration of an object, not just the current state. When ransomware encrypts a file and writes the encrypted version back to storage, the original remains available as a previous version, ready to be retrieved and restored.

Alone, versioning is insufficient. Nothing prevents a sufficiently privileged attacker from deleting all versions simultaneously. Combined with Object Lock, though, it becomes a different proposition entirely. Locked versions cannot be deleted during their retention window, regardless of how the deletion request is authenticated.

The practical implication: even if an attacker compromises both your primary environment and the credentials your backup agent uses, the locked previous versions in Stornox remain untouchable. Recovery doesn't require negotiation. It requires a restore job.

Versioning does increase storage consumption. Each object version is billed as a full object. For organizations keeping 30-day version histories on large datasets, this can meaningfully affect storage costs. Consider this when designing retention policies, not after the first billing cycle.

How Stornox Implements Both — and Why the Combination Matters

Stornox treats immutability as a first-class architectural feature, not a checkbox added to meet a feature matrix. Both Object Lock and versioning are available on all storage tiers, enabled at bucket creation, and enforced at the platform layer rather than through a middleware layer that could itself be compromised.

The configuration is deliberately simple. When you provision a bucket through the Stornox console or API, you set Object Lock mode and retention duration once. After that, every write to the bucket is automatically covered. There's no per-object tagging requirement, no scheduled job to apply retention policies, and no dependency on the backup application to behave correctly.

This matters more than most documentation makes clear. In a ransomware scenario, you need a recovery path that doesn't depend on any component that was also under attack. Stornox's enforcement sits outside the blast radius.

Compliance Modes vs. Governance Mode: Choosing the Right Policy

Object Lock in S3-compatible systems offers two behavioral modes. The right choice depends on your operational model, not just your threat model.

Compliance mode is absolute. No user, including the storage account owner, can delete or modify a locked object before its retention period ends. This is the appropriate setting for organizations with regulatory obligations such as financial services, healthcare, and legal archives. Nothing overrides it.

Governance mode allows designated privileged users to delete locked objects with explicit permission. This provides operational flexibility when a backup application writes a corrupt or test object that needs to be removed, an authorized administrator can do so without waiting for the retention period to expire.

Governance mode's flexibility can also be a weakness for ransomware protection. If an attacker compromises an account with override permissions, that protection dissolves. For organizations whose primary goal is ransomware resilience rather than regulatory compliance, Compliance mode is the correct choice.

Cost-Efficient Cloud Storage Without Sacrificing Protection

A concern that surfaces often in enterprise evaluations is whether immutable cloud storage carries a premium that makes it impractical at scale. At Stornox, the architecture is designed to deliver cost-efficient cloud storage without treating security as a feature tier.

Object Lock and versioning don't require a higher storage class or a separate product SKU at Stornox. Organizations storing multi-terabyte backup repositories can enable full immutability without stepping into an enterprise pricing tier reserved for large contracts.

Cost management matters most in the design of retention windows. Stornox's lifecycle policies automatically tier or delete expired versions after the lock period ends, keeping active storage consumption predictable. A reasonable estimate for most mid-market organizations is that properly configured lifecycle rules reduce effective storage costs by 30–40% compared to a naive "keep everything" implementation.

What IT Leaders Should Configure Before the Next Incident

Configuration decisions made before an attack determine what recovery looks like after one. A few specific recommendations based on common deployment patterns:

Start with Compliance mode on your primary backup target. Set a minimum 30-day retention window to help cover a typical ransomware dwell time before detection. Pair this with versioning enabled at the bucket level so intermediate backup versions are preserved throughout the window.

Create a dedicated Stornox bucket for backup data, separate from any general-purpose storage your applications write to. This isolates backup credentials and reduces the risk that a compromised application credential set can touch recovery infrastructure.

Finally, test restoration quarterly. Object Lock prevents deletion; it doesn't validate backup integrity. A quarterly restore drill against a Stornox-hosted backup confirms the chain that immutability, versioning, and restore fidelity are working as intended.

If you're evaluating how to strengthen your backup infrastructure against ransomware or need guidance on configuring Object Lock and versioning policies for your specific environment, contact the Stornox team to discuss your requirements. Getting the architecture right before an incident costs far less than recovering from one without it.