Ransomware crews worked out some time ago that encrypting production data is only half the job. The other half is destroying the backups, so that paying is the only way out. That is why "immutable backups" now appears on every security questionnaire an MSP is asked to complete. The mechanism behind the phrase is object lock, and until recently it mostly arrived bundled with an enterprise backup suite and enterprise pricing. It no longer has to.

This article covers what immutability does and does not protect against, how object lock works on Duplicati Storage, how the Duplicati client restores after an attack, and the retention decisions to make before you turn it on. The mechanics are the same on any object store that supports locking; Duplicati Storage is the worked example.

What immutability actually stops

Object lock is a promise made by the storage provider: once a file is written, the provider refuses to delete or overwrite it until a retention date has passed. The important word is provider. The lock is enforced by the storage service, not by the backup software, so it holds even when the backup software, and the machine it runs on, are fully compromised.

That closes the specific hole ransomware exploits. A backup client needs credentials to write to storage, and an attacker who controls the machine has those credentials. Without a lock, they can list the bucket and delete everything, or overwrite the backup volumes with garbage and wait for the retention schedule to age out the good copies. With a lock, those delete and overwrite calls are rejected at the storage layer. The same protection applies to a leaked API key used from elsewhere, to an insider holding the backup credentials, and to the honest mistake of a misconfigured cleanup job.

What it does not stop

Immutability is narrow by design. It protects the files already in the bucket; it says nothing about what goes in next. If a machine has already been encrypted when the next backup runs, the backup will faithfully upload the encrypted files as a new version. The good data is still there in the earlier versions, but you need a client that knows how to reach it, which is the subject of a later section.

It does not protect against someone with access to the storage account itself, as opposed to the backup credentials. In governance mode an administrator with sufficient privilege can lift a lock; compliance mode removes that escape hatch for everyone, including the vendor. It does not protect your encryption passphrase, which never leaves your machines. It does not make a recovery faster on its own: a locked bucket full of versions is only useful if someone has rehearsed restoring from it. And it does not make retention decisions for you; a lock is a commitment to keep paying for those bytes until the date passes.

Object lock on Duplicati Storage

Duplicati Storage is the managed destination built into the Duplicati Console: no buckets to create, no credentials to hand out, and every backup is encrypted on the machine before upload. Object lock is a setting layered on top, configured under Settings → Storage. You set an organization-wide default, and any machine can extend it.

Three choices make up the policy. Object lock is enabled or disabled. Retention mode is governance or compliance; governance is the default and the sensible place to start, because an organization owner can still undo it while you learn how the lock interacts with your schedules. Compliance means locked files cannot be deleted or overwritten by anyone, including Duplicati. Default retention is either a fixed number of days applied to every uploaded file, or none, in which case each backup job sets its own duration with the --remote-file-lock-duration option.

Two consequences follow from how object storage works. First, object lock is set when a bucket is created, so enabling it for a machine with an existing backup means a bucket migration: the files are copied to a new locked bucket, which counts twice against quota until the old one is removed, and the migration cannot be reversed. Second, enabling lock also keeps earlier versions of every file. When a backup volume is replaced or deleted, the previous version stays, locked, until its retention expires. That is what makes the recovery story below possible.

Client-side support for object lock on Duplicati Storage is currently in the canary release channel. Canary is where new features land first before moving to beta and stable, so to try this today, run a canary build, ideally on a non-critical machine first.

A version-aware client

Most backup tools treat the destination as a flat folder: the files that are there now are the files that exist. That model breaks down after an attack, because the bucket now holds both the good versions and whatever the attacker wrote on top of them.

Duplicati handles this with the --remote-point-in-time option. You give the client a timestamp for the last point you consider good, either absolute or relative, such as 3D for three days ago. From then on the client operates on the destination as it looked at that moment: when it lists the bucket it sees the version of each file that was current at that time, ignores files deleted before it, and does not see anything created after it. Backup volumes that were overwritten with junk at 02:00 on Tuesday are, to a client pinned to Monday evening, simply the Monday versions.

While that option is set, the destination is strictly read-only. Uploads, deletes, renames and lock changes are all refused, so a restore cannot accidentally disturb the evidence. The one thing you still decide yourself is the timestamp. Pick a time before the incident, and avoid moments when a backup was mid-run.

Retention is a real decision

Object lock removes the option to prune early. Normally Duplicati's retention policy deletes old versions on a schedule and a compact step reclaims the space. With locked volumes those deletes are deferred until the lock expires, and on Duplicati Storage the space continues to count toward quota until roughly 24 hours after the lock lapses. Set a 90-day lock on a job with a 30-day retention policy and you will pay for about 90 days of data, not 30.

So choose the lock duration deliberately. It should be longer than the time an incident could plausibly go unnoticed, because that is the window in which the good versions must survive. It should be short enough that the cost is one you have agreed to. And it should line up with the retention policy on the job, so the two are not working against each other. A reasonable path is to start in governance mode with a short lock, watch usage across a full cycle of backups and compacts, and then lengthen the lock and consider compliance mode once the numbers are understood.

What a restore looks like

Say a managed endpoint is encrypted overnight and the attacker also tries to wipe the backups. The locked bucket rejects the deletes; the overwrites land as new versions on top of locked old ones.

The recovery never touches the compromised machine. Stop scheduled backups, compacts and repairs against that destination so nothing modifies versions that are not yet protected. From the Console, issue a temporary read-only restore key for the machine; it expires after seven days and can be revoked earlier. On a clean machine, run a direct restore from backup files, which builds a temporary database from the remote data, so the local database on the infected host is not needed. Add --remote-point-in-time with a timestamp before the incident, use list or find to confirm the versions you expect are there, and restore.

Afterwards the damaged versions are still in the bucket, because the lock applies to them too. Rotate the credentials, fix the cause, and point new backups at a fresh destination. Keep the old bucket until the restore is verified; the lock will release it when the retention date passes.

Try it before you need it

Immutable backups used to mean an appliance, a vault license or an enterprise agreement. The same guarantee is now a toggle in the Duplicati Console, with lock mode and retention set per organization or per machine. If you manage backups for others, start a Duplicati Console trial, enable object lock on Duplicati Storage in governance mode, and run one point-in-time restore before the day you have to.