Immutable Backups and Ransomware Recovery

Ransomware crews delete backups before they encrypt anything, because a victim with working backups does not pay. That makes backup immutability a security control rather than a storage feature, and most things described as immutable do not survive an attacker holding your own credentials. This covers what actually does, how to configure it, and the retention mistake that leaves you restoring a compromised environment.

Modern ransomware crews do not encrypt your servers and hope. They spend days inside the network first, and one of the things they look for is the backup system, because a victim with working backups does not pay. Deleting or encrypting the backups is not a side effect of the attack. It is a prerequisite for it.

MassiveGRID Backup Services: R1Soft block-level incremental backups · AES-256 encryption · RAID10 storage in Tier-3 and Tier-4 datacenters · bare-metal restore · US and EU storage locations · $0.01 per GB with unlimited backup operations · 2 free snapshots per VPS

Backup Services · Disaster Recovery · HA Cloud Storage

What Immutable Actually Means

The word is used loosely enough to be misleading, so be precise. Immutable means a written object cannot be modified or deleted until a retention period expires, and that this is enforced by the storage system rather than by permissions you could change.

That last clause is the whole point. Four things are commonly called immutable and only some of them are:

The threat model that matters is not a careless user. It is an attacker holding valid credentials for your infrastructure, including the ones your backup job uses. Any protection that a sufficiently privileged account can switch off is not protection against that.

Object Lock and Its Two Modes

S3-compatible object storage implements this through Object Lock, which requires versioning on the bucket and comes in two modes that differ in exactly the way that decides whether it helps.

Governance mode prevents deletion, and a user with a specific bypass permission can override it. Useful against mistakes. Useless against an attacker who has the credentials that carry that permission.

Compliance mode prevents deletion by anyone, including the account root, until the retention period expires. Nobody can shorten it. That is genuine immutability and it comes with a consequence people underestimate: you cannot delete that data early either, including if you wrote a terabyte by mistake or wrote something you were not supposed to retain.

Legal Hold is a third, separate flag that blocks deletion indefinitely until explicitly removed, independent of any retention period.

Set retention deliberately. Long enough to cover the attacker dwell time you might not detect, and short enough that the storage cost is bearable. Thirty days is a common middle; if intrusions in your sector are typically discovered later than that, longer.

The Dwell Time Problem

Here is the failure that catches organisations who did everything else right. Attackers are frequently inside a network for weeks before triggering encryption. If your retention is seven days and the intrusion started three weeks ago, every backup you hold was taken while the environment was already compromised.

Restoring from those backups restores the attacker's access along with your data, and the second encryption event follows shortly.

Two implications for design. Retention should exceed plausible dwell time, which argues for keeping monthly copies for longer than the operational rotation needs. And restoration after a ransomware event is not a restore, it is a rebuild: fresh hosts, credentials rotated, then data restored, with the restored data treated as suspect until checked.

Building It

The pattern that works has three properties: a copy on storage that cannot be deleted, credentials that cannot delete it even if stolen, and a verification step so you know the copy is good.

With MinIO, which our MinIO guide covers installing, Object Lock must be enabled when the bucket is created and cannot be added afterwards:

mc mb --with-lock myminio/backups-immutable
mc retention set --default COMPLIANCE 30d myminio/backups-immutable
mc retention info myminio/backups-immutable

Then give the backup job a credential that can write and read and cannot delete or alter retention. This is the control that does the real work, and it is the one most often skipped:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "s3:PutObject",
      "s3:GetObject",
      "s3:ListBucket",
      "s3:GetBucketVersioning"
    ],
    "Resource": [
      "arn:aws:s3:::backups-immutable",
      "arn:aws:s3:::backups-immutable/*"
    ]
  }]
}

Note what is absent: no s3:DeleteObject, no s3:DeleteObjectVersion, no s3:PutObjectRetention, no s3:BypassGovernanceRetention. A credential harvested from that server cannot remove a single stored backup.

For repository-based tools, append-only mode gives a weaker version of the same idea. Borg supports it on the repository server, and restic's REST server has an append-only flag. A compromised client can write new data and cannot prune history. It does not protect against someone with access to the storage host itself, so treat it as a layer rather than the answer.

Verification Is Part of the Control

An immutable copy of a corrupt backup is a permanently preserved corrupt backup. The extension of the familiar rule is sometimes written 3-2-1-1-0: the usual three copies on two media with one off-site, plus one immutable or offline copy, and zero errors on verification. Our post on off-site backups covers the first part.

Verification means reading the data back and checking it, not confirming that the job exited zero:

restic -r s3:https://s3.example.com/backups-immutable check --read-data-subset=10%
borg check --verify-data /path/to/repo

Reading everything is expensive, so sample continuously and read fully on a slower cycle. Then, separately, restore something and use it. A verified archive proves the bytes are intact; only a restore proves the database starts.

What This Costs

Immutability changes the cost profile in a way worth modelling before you enable it, because with compliance mode you cannot correct a mistake by deleting.

Versioning plus retention means every version of every object persists for the full period. A daily backup with 30-day compliance retention holds 30 copies whether or not you want them, and a job that accidentally writes a full backup instead of an incremental leaves that full copy in place for a month.

At MassiveGRID's backup pricing of $0.01 per GB with unlimited backup operations, a terabyte of retained backup data is around $10 a month, which makes the arithmetic straightforward. Model the peak, not the average, and set retention with the knowledge that you cannot shorten it later for data already written.

What the Platform Gives You, and What You Add

Being precise here is more useful than a claim of ransomware-proof infrastructure, which no provider can honestly make.

MassiveGRID Backup Services gives you R1Soft block-level incremental backups with AES-256 encryption, held on separate RAID10 storage in Tier-3 and Tier-4 datacenters rather than on the server being protected, with bare-metal restore, US and EU storage locations, unlimited backup operations at $0.01 per GB and two free snapshots per VPS. Separation of the backup store from the protected host is the foundation, and block-level incrementals make frequent copies cheap enough that a short recovery point objective is affordable.

What that does not by itself provide is cryptographic immutability, which is a property of object storage with Object Lock. If your threat model includes an attacker with your infrastructure credentials, and for most organisations it should, add an S3-compatible target in compliance mode with a write-only credential, as above, alongside the platform backups. The two together give you a fast local restore path and a copy that cannot be destroyed.

The storage underneath the platform is Ceph with three-way replication across independent NVMe drives, which protects against hardware failure and is a different problem from malicious deletion. Worth separating those in your own planning, because conflating them is how organisations conclude they are covered when they are not. Disaster recovery covers the wider plan, and our guide to backup encryption and key management covers the risk that your own encryption becomes the reason a restore fails.