Immutable Backup (WORM)

A Backup Ransomware Cannot Delete
Immutable Copies via S3 Object Lock

The first move in almost every ransomware attack is the same: delete the backups first. If your backup can be deleted, you end up negotiating. With Object Lock enabled, delete and overwrite operations are refused at the storage layer — even total control of your server does not reach that copy.

🎁 Start Free — 14 Days See Pricing

No credit card required · 14-day free trial

Threat Model

Why an Ordinary Backup Is Not Enough

Once an attacker is inside, they hold the same permissions you do — including the right to delete.

🎯

Backups are targeted first

Modern ransomware hunts for reachable backups and deletes them before encrypting anything.

🔑

Stolen credentials

If your storage keys are compromised, an attacker can delete your cloud backups too.

🕐

Patient attackers

An intruder may wait weeks so that every backup in your retention window contains their code.

🧑

Insider error or intent

An authorised user deleting data — by accident or deliberately — has the same effect.

🗑

Misconfigured cleanup

A badly configured retention rule can remove backups you meant to keep.

⚖️

Proving integrity

Some audits require evidence that a backup has not been altered; WORM provides it.

How It Works

The Object Lock Chain

1️⃣

A locked bucket

You create an S3 bucket with Object Lock enabled — in your own account.

2️⃣

You choose the period

You decide how many days each backup stays immutable.

3️⃣

Written with the lock

Every backup is written with lock metadata; delete requests are refused.

4️⃣

Fail-closed

If the lock cannot be applied the backup is not counted as successful — no silently unprotected copy is created.

Know this before you enable it

On most services Object Lock can only be enabled when the bucket is created and cannot be turned on later. If you plan to use WORM, create the bucket with it enabled from the start.

During the lock period you cannot delete the file either. That is inherent to the protection — otherwise an attacker could delete it too. Storage costs continue to accrue, so start with a short period (7–14 days) and extend it as your needs become clear.

Services supporting Object Lock: Amazon S3 and S3-compatible providers such as Wasabi, Backblaze B2 and MinIO. Google Drive, Dropbox, OneDrive and Yandex.Disk do not offer it, so WORM is unavailable on those targets.

FAQ

Immutable Backup (WORM) — Frequently Asked Questions

What is an immutable (WORM) backup?

WORM stands for write once, read many. Once the backup file is written to storage it cannot be modified or deleted for a period you define. The restriction is enforced at the storage provider's own layer rather than in the application, so the file is protected even if administrative access is compromised.

Can ransomware delete this backup?

No. The typical first step of a ransomware attack is to find and delete or encrypt backups. On a copy with Object Lock enabled, delete and overwrite operations are refused by the storage provider; even with full access to your server and panel, an attacker cannot touch it. The file remains intact until the lock period expires.

What do I need to use it?

An S3 bucket that supports Object Lock and was created with the feature enabled. Amazon S3 offers it, as do S3-compatible services such as Wasabi, Backblaze B2 and MinIO. The bucket is in your account, so the lock policy is under your control.

Can Object Lock be enabled after the bucket is created?

Usually not. On most S3-compatible services Object Lock can only be enabled at bucket creation and cannot be added afterwards, so plan for it from the start.

What happens when the lock period expires?

The file becomes an ordinary object that can be deleted again. When choosing the period, weigh both your recovery needs and your storage costs — during the period you cannot delete the file either.

A Backup Ransomware Cannot Delete Immutable Copies via S3 Object Lock