Ransomware Resistant Backups: Object Lock, Versioning and Separating Writer from Deleter

Most backup strategies rest on one assumption: if data is corrupted or hardware dies, you restore from backup. Ransomware inverts that assumption, because an attacker looks for the backups first. A backup repository reachable from the production server is a repository reachable by whoever takes over that server. A backup that can be both written and deleted with the same credential is technically a backup, but in an attack scenario it does not exist.

This post is about the mechanisms that make a backup undeletable, and about how far each of them actually protects you.

Not the number of copies, but their independence

The classic 3-2-1 rule (three copies, two media types, one offsite) was designed for hardware failure. A ransomware scenario adds two requirements: one copy must be immutable, and restores must be verified. People call this 3-2-1-1-0, and the weight sits in the last two digits.

What needs measuring here is not the copy count but whether the copies share a common failure point. If all three copies live in the same object storage account, that account's key is a single point of failure. Likewise, if the machine that takes the backup also has permission to delete it, that machine is a single point of failure. A useful way to pose the question: how many commands would someone with full access to production need in order to destroy every restore point? If the answer is one, the number of copies is irrelevant.

Object lock: forbidding deletion at the storage layer

In S3 compatible object storage, the mechanism for this is object lock. With versioning enabled, every write creates a new version and a delete merely places a delete marker; a lock makes the storage refuse to overwrite or remove a version for a stated period. There are two modes, and the difference matters operationally.

In GOVERNANCE mode, a user holding a specific permission can bypass the lock. That is useful for correcting misconfiguration, and it offers no protection if an attacker obtains that permission. In COMPLIANCE mode nobody, including the account owner, can delete the object before its retention expires. That is real protection, and the same property is its biggest risk: terabytes accidentally written with a ten year retention mean ten years of paying for them. Trying the feature with a short retention, say seven days, and measuring the behaviour is the step first time adopters should not skip.

A minimum sane arrangement looks like this: versioning enabled on the bucket, a default retention period configured, and a lifecycle rule that removes non current versions once the lock has expired. Enabling versioning without a lifecycle rule is the most common cost mistake: everything deleted lingers as a version, the bill grows quietly, and nobody can explain where it went.

Separating identities: the writer should not be the deleter

Even on storage without object lock, you can build most of the defence on the identity side. The identity that takes backups gets append only rights; deletion and retention enforcement belong to a separate identity, preferably a job running on a separate machine.

In practice this means a storage policy that grants writes but not DeleteObject or PutObjectRetention. Backup tooling has its counterpart: the server components of common backup tools can run in append only mode, where a client can add new data but cannot remove what exists. Pruning then happens on the repository side, on a schedule independent of the client.

The cost of this arrangement is that deleting backups is no longer easy. A badly written retention rule needs an extra step to clean up. What it buys is that a full compromise of the production server is not enough to destroy the restore points.

Encryption and where the key lives

Encrypting backups protects confidentiality and does nothing about deletion. Worse, misconfigured, it becomes a cause of loss on its own: if the encryption key exists only on the production server, losing that server makes the backups unreadable. The key should exist in at least two independent places, one of them offline, and the restore drill should fetch the key from that second place. If your drill reads the key from production, what you tested is not the disaster scenario.

Comparing the approaches

Filesystem snapshots (ZFS, btrfs, LVM) are cheap and fast, giving a rollback in seconds. But they live on the same machine, in the same pool; if the root account managing that pool is compromised, the snapshots can be destroyed too. Excellent against operational mistakes, weak against a deliberate attack.

Remote storage with object lock has the inverse profile: restores are slower and there is egress cost, but it offers genuine resistance to deletion. Cold storage and tape are the best on cost and isolation, the worst on time to restore.

In practice the right answer is not picking one but layering them: snapshots for daily operational mistakes, regular full backups for corruption, and a lock protected remote copy for deliberate deletion. A setup that relies on snapshots alone does not, in my view, count as backed up; a setup that relies only on the remote copy loses hours on every small mistake.

Traps

Retention arithmetic may not work the way you expect. Because the lock period is written per object, changing a bucket's default retention later does not affect existing objects. In a bucket where the team says "we now lock for thirty days", objects written before yesterday still carry the old period.

Clock skew is another trap. Retention is stored as an absolute timestamp, so if a machine's clock runs ahead, the lock you write is shorter than intended.

Some storage services use the word immutable while still allowing deletion from an admin console. Measure that by experiment rather than by trusting documentation: write a test object and try to delete it with every privileged identity you have. If it can be deleted, that storage is not suitable for this scenario.

Finally, the backup system's own configuration needs backing up. If the repository key, the retention rules and the restore steps exist only on the machine that got compromised, what you hold is a readable archive that nobody knows how to open.

When you do not need all of this

For data that can be regenerated, this structure is overkill. Build artifacts, caches, derived thumbnails: if their source still exists, keep their backups cheap. Making that distinction early is the easiest way to put the cost in the right place. Which data stops the business if it disappears, and which data gets rebuilt? Object lock, key separation and identity separation apply only to the first group.