🔒 S3 Object Lock 🛡 Ransomware Proof ⏳ You Set the Period 🚫 Fail-Closed 🔒 S3 Object Lock 🛡 Ransomware Proof ⏳ You Set the Period 🚫 Fail-Closed
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. In COMPLIANCE mode, for the lock period nobody — not even the account owner — can delete that copy, even if your server is taken over; in GOVERNANCE mode an account with special permission can remove the lock. This feature works only in an S3-compatible bucket with Object Lock enabled.

🎁 Start Free See Pricing

No credit card required · free trial until the end of the year

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 choose the lock mode (COMPLIANCE or GOVERNANCE) and how many days (1–3650) 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, Yandex.Disk, your own server and the Receiver Module do not offer it, so WORM is unavailable on those destinations. Whether the locked copy is really still at the destination is also checked by the presence layer of the 8-layer verification; if an archive can't be found, you see a warning in the panel and receive an email.

FAQ

Immutable Backup (WORM) — Frequently Asked Questions

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. In COMPLIANCE mode the file stays protected for the lock period even if administrative access is compromised; in GOVERNANCE mode an account with special permission can remove the lock.
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. In COMPLIANCE mode, even an attacker with access to your server and cloud keys cannot delete the locked copy until the period ends; in GOVERNANCE mode an account with special permission can remove the lock, so COMPLIANCE is the strongest protection. The lock protects copies that have already been written; the file stays as it is until the lock period expires.
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.
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.
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.
This is an important caveat: for the whole lock period you can't delete the file either, and storage costs keep accruing. For large backups we recommend starting with a short period (for example 7–14 days) and increasing it as needed.

Keep One Copy an Attacker Cannot Reach

No extra charge for WORM; it runs in your own S3 bucket. Free until the end of the year.

Create Free Account

See pricing →