restowbackup
Try demoBuy license

Immutable backups, WORM, air gaps and ransomware: what protects a backup from an attacker

CISA reports that most ransomware actors try to find and delete or encrypt accessible backups, so that restoring is impossible unless the ransom is paid. Two controls answer that. An immutable backup sits on write-once storage, such as S3 Object Lock, that refuses to change or delete data until a set date. An offline or air-gapped copy is not connected when an attacker is on the network. Each helps against a different attack, neither covers everything, and a backup that has never been restored is protected by neither.

Lucas Flores By , IT Systeme Flores UG. Last updated

How do attackers go after backups?

The CISA #StopRansomware Guide says that most ransomware actors try to find and then delete or encrypt accessible backups, so that restoring is impossible unless the ransom is paid. They look for credentials stored in the environment and use them on backup solutions, and they use public exploits against backup solutions that are not patched. CISA also warns that an automated cloud backup that only syncs files may not be enough: if local files are encrypted, the encrypted files are synced and can overwrite good data in the cloud.

MITRE ATT&CK describes the techniques in more detail under "Inhibit System Recovery". Adversaries delete Windows shadow copies and the backup catalog with built-in tools, delete virtual machine snapshots, and delete online backups kept on network storage or in folders synced to the cloud. In cloud environments they turn off versioning and backup policies and then delete snapshots, backups and earlier object versions. The BSI, the German federal office for information security, puts it as common practice that attackers with administrator rights search for all backups and encrypt them like production systems.

The common thread is access. An attacker uses the same credentials, the same network path and the same administrator role that your backup software uses. A backup that the software can delete, an attacker with that software's access can delete too. Both controls below are ways of making that access matter less.

What do immutability and WORM do?

Immutable means the storage enforces that data cannot be changed or deleted for a set period, rather than relying on the backup software to behave. WORM, write once read many, is the model: the SNIA Dictionary describes it as storage for fixed content that preserves what is written to it in an immutable fashion.

The widely used example is Amazon S3 Object Lock. It protects an individual object version in one of two ways, a retention period with an end date or a legal hold with none, and it works only in buckets with versioning turned on. A permanent delete of a locked version is refused. A plain delete without a version ID is accepted but only adds a delete marker on top, so the locked versions stay underneath. Other S3-compatible services offer Object Lock too, with their own limits: Hetzner's documentation, for example, says it must be enabled when the bucket is created and cannot be added later.

What is the difference between governance mode and compliance mode?

A retention period has one of two modes, and the choice is the heart of the matter:

Question Governance mode Compliance mode
Who can delete before the date Users with a special permission (s3:BypassGovernanceRetention) who ask for the bypass explicitly. Nobody, including the root user of the account.
Can the lock be shortened or removed Yes, with that permission. No. The mode cannot be changed and the period cannot be shortened.
What it suits Protection against mistakes and most accounts, with a way out; trying a retention setting before committing. Data that nobody may delete during the period, for instance for a regulation that says so.
The catch An attacker who obtains a role with the bypass permission can remove the lock. The S3 console sends the bypass header by default. A wrong period cannot be undone, and AWS names deleting the whole account as the only way to remove the data earlier.

A legal hold gives the same protection as a retention period without an end date, and it stays until someone with the right permission removes it. CISA adds a caution that applies to all of it: immutable storage does not meet the criteria of certain regulations, and a misconfiguration can impose significant cost, because you pay for what you cannot delete.

What does immutability not cover?

What do offline copies and air gaps add?

NIST describes an air gap as an interface between two systems that are not connected physically, where any logical connection is not automated. For backups it means a copy that is disconnected when nobody is writing to it. The BSI's list of measures asks for at least one offline copy that is separated from the other systems after the backup, so it is protected from remote attacks. Its examples are separate tapes, a separate archive that needs physical access, or cloud storage that is completely separated from your own network. It also asks you to check the separation regularly, for example by letting a domain administrator try to reach the copies, which should fail, and to keep copies in different places. CISA's guide likewise asks for offline, encrypted backups that are tested.

Tape is the classic offline medium. The LTO Program lists write-once cartridges from LTO-3 and hardware encryption from LTO-4, and it describes tapes taken offline and moved away as physically separated from attackers. The price is process: someone has to rotate the media, the offline copy is as old as the last rotation, and restoring from tape is slower than from disk.

Which control helps against which attack?

Attack What helps What does not
Files are encrypted at the source and the backup follows Versioned restore points that go back before the infection; restore checks. A plain sync or mirror, which copies the damage.
Stolen administrator credentials are used to delete backups Compliance-mode lock; separate credentials for the backup storage; multi-factor authentication for deletion. Governance mode, if the stolen role holds the bypass permission.
The backup server itself is taken over Storage that enforces the lock; sources that can only add; an offline copy. Immutability enforced only by the backup application.
The provider account is lost or closed A copy at another provider under another login. A second bucket in the same account.
Older restore points are already infected A lock period longer than the time an intruder can go unnoticed; scanning before a restore. A short lock that expires first.
Data is stolen and publication is threatened Storing less; encryption and access control of the data itself. Any backup control.

What is a sensible minimum for a small business?

  1. Follow the 3-2-1-1-0 idea: at least one copy that is immutable or offline, and a restore that has been tried.
  2. Give the backup storage credentials that differ from the administrator accounts of the systems you protect.
  3. Make sure someone is told when a backup fails or is overdue, because a deleted backup looks like a missing one.
  4. Keep restore points long enough to reach back before an intruder could have been in, and check what a restore brings back before you reconnect it.
  5. Choose the control you can run. An offline disk that is rotated every week and tested beats an Object Lock bucket that nobody has checked.

How Restow handles this

Since 0.4.0, Restow can lock backup data itself, and it judges every new restore point for signs of ransomware. This is what that does, what it leaves to you and where it stops.

Immutable backups, per repository

Every repository has an immutability setting of its own. It is off until an administrator turns it on under Repositories ("Change immutability"), and nothing is locked before that.

  • S3 with Object Lock, in compliance or governance mode, for 1 to 3650 days. Turning it on checks the bucket and refuses one without Object Lock. Object Lock can only be enabled when a bucket is created, so an existing bucket without it cannot be used. Every locked object is written with a retain-until date of the period plus 7 days, and the daily retention job renews every object still in use once the last renewal is 6 days old, because deduplication lets a new restore point rest on packs written months ago. Restow never sends the governance bypass header. When retention, garbage collection or a prune meets an object that is still locked, the deletion counts as "not yet": the restore point stays visible and restorable, and the space comes back once the lock has run out.
  • A directory (the Docker volume, an NFS share) gets only a deletion delay: Restow's own code refuses to delete or overwrite a backup file before the period has passed. It protects against misuse of Restow, such as a stolen administrator account or a retention policy shortened to delete restore points. It does not protect against anyone with access to the server or the share, and the interface says it is not immutability.

Locked are the packs, the committed manifests and the wrapped keys of the chunk store (Microsoft 365 including SharePoint, IMAP, Proxmox VE VM disks and the message content of the archive) and the data, snapshots, keys and config objects of every restic repository (servers and clients, file shares, Proxmox VE containers). Not locked are checkpoints, staging, exports and downloads, and restic's own locks and index files; restic repair index rebuilds the index from the locked packs. The archive's item records keep their own retention, as before. A restore point shows "Immutable until" with a date, in green only when the storage itself reported a compliance lock. Raising the protection is open to whoever may configure the repository; lowering it (fewer days, a weaker mode, off) is for the provider owner with a recent sign-in, applies only to data written from then on, and is audited.

What it does not cover

  • Someone who controls Restow can stop new locks and the renewal. What is locked stays locked until its date, but new backups after that are not protected.
  • A governance lock is lifted by any account with s3:BypassGovernanceRetention. Give Restow's key a policy without it, and without s3:PutBucketObjectLockConfiguration and s3:PutBucketVersioning, or use compliance mode.
  • Delete markers and newer versions can hide locked data. The locked versions stay and can be brought back, but it takes work.
  • The master key is not in the bucket. Keep a copy away from the server, or locked data cannot be opened.
  • The installation's default repository cannot be made immutable: give the tenant a repository of its own, or an immutable copy. A tenant whose retention schedule was deleted is not renewed, and the space of deleted data comes back only after its lock has run out.
  • Testing. Immutable backups were tested against a simulated S3 service with Object Lock, not yet against a real S3 service with Object Lock, and not against a real Hetzner bucket. We have not tested Restow against a bucket with a default Object Lock retention; treat that combination as untested.

See the storage page for the whole picture, including the permissions the access key needs.

Ransomware detection

Every new restore point is judged for signs of ransomware from data the backup already has: the amount of change against the object's own history, deletions, renamed extensions, known ransomware names, sampled files that look encrypted, and data that neither compresses nor deduplicates. A suspicious restore point gets a red badge, the restore views offer the newest one without findings, an alert goes out once per attack, and retention of that object is paused until an administrator marks the finding as a false alarm or releases the hold, so the clean older restore points are not pruned while encrypted ones pile up. It is a tripwire, not a virus scanner; a restore point without findings proves nothing; and it was tested with simulated attacks, not with live ransomware. See ransomware detection.

What Restow does besides

  • Append-only agents for servers and clients. The agent can add backups but never delete or overwrite them. The Restow server enforces this, and retention and pruning run only on the server. The agent never holds the credentials of the storage; a stolen agent secret would allow writing new backups to that machine's repository and reading it, but not deleting anything. Proxmox VE nodes (a preview) can read and add backups of their own cluster and cannot delete them.
  • Encryption. Every chunk is encrypted with AES-256-GCM before it is written, with a separate key per tenant. That protects confidentiality; it does not stop deletion.
  • A second copy under separate credentials. Every repository has its own access keys, and a copy repository can live at another provider, with its own immutability setting. A copy covers mail, calendar, contacts, OneDrive, SharePoint, IMAP and Proxmox VE VM data; servers, clients, file shares and Proxmox VE containers stay in the primary repository, so for them the primary has to be the immutable one. The Restow server holds the credentials of every repository and runs retention, so someone who takes over that server can reach both copies. Protect the server and the master key accordingly.
  • Detection. A weekly restore check reads a sample of each backup back and compares it with the recorded checksums, so damaged or unreadable data shows up. The storage check reads a sample every week and every stored pack every month. Reads and restores are written to a hash-chained audit log, and alerts cover failed and overdue backups.

What Restow leaves to you

Restow has no feature to disconnect or rotate media, so an offline copy has to be made outside Restow, and you should test a restore from it, keys included. It cannot tell whether your copy repository shares a failure domain with the primary; choosing another provider or site is your decision, and so is choosing the lock period. See encryption and key handling, server and client backup and storage.

Frequently asked questions

What is the difference between governance mode and compliance mode?

Both are retention modes of S3 Object Lock. In governance mode most users cannot delete or change a locked object version, but a user with a special permission can bypass the lock. In compliance mode nobody can, not even the root user of the account, and the period cannot be shortened; AWS names deleting the whole account as the only way around it before the date.

Is an immutable backup the same as an air-gapped backup?

No. An immutable backup sits on connected storage that refuses to change or delete data until a date. An air-gapped or offline copy is not connected when an attacker is on your network. The first guards against deletion by whoever can reach the storage, the second against anyone who cannot physically reach the copy, and they fail in different ways.

Does immutability protect me from ransomware?

It protects stored restore points from being deleted or overwritten for the lock period. It does not clean the data that was backed up before an infection, so older restore points still matter, and it does not stop an attacker from stealing data. Test restores and keep restore points from before an intruder could have been in the network.

How long should a lock period be?

There is no standard. The BSI notes that attackers sometimes stay in a network for several weeks before they strike, so a lock shorter than that may leave only infected restore points. A longer lock costs storage and cannot be undone in compliance mode, so choose a period you can pay for and test it before you rely on it.

Does Restow support Object Lock?

Yes, since 0.4.0, per repository. On an S3 bucket created with Object Lock, Restow can lock backup data in compliance or governance mode for 1 to 3650 days and renews the lock while the data is in use. A directory only gets a deletion delay, which is not immutability. It does not help if someone who controls Restow stops the locks, a governance lock can be lifted with the bypass permission, and it was tested against a simulated S3 service, not yet a real one. An offline copy still has to be made outside Restow.

Does Restow detect ransomware?

It judges every new restore point for signs of it and pauses retention of the object until an administrator resolves the finding, so the clean older restore points are not pruned away. It is a tripwire, not a virus scanner, and a restore point without findings proves nothing. It was tested with simulated attacks, not with live ransomware.

Sources

Read on 16 October 2026.

  1. CISA: #StopRansomware Guide, version 3.0 (October 2023). Part 1: offline, encrypted and tested backups; ransomware actors try to delete or encrypt accessible backups; delete protection or object lock
  2. MITRE ATT&CK: T1490 Inhibit System Recovery. How adversaries delete shadow copies, backup catalogs, online backups and cloud snapshots
  3. MITRE ATT&CK: T1485 Data Destruction. Backups stored off the affected system, and multi-factor authentication for deletion on cloud storage
  4. BSI: Maßnahmenkatalog Ransomware, Arbeitspapier, version 1.0 (23 February 2022), chapter 2 Backups. At least one offline copy, a regular check that the separation holds, copies in different places, and what backups cannot protect against
  5. BSI: Top 10 Ransomware-Maßnahmen, Backups, Datensicherungskonzept und zentrale Datenhaltung. A backup as the most important preventive measure, offline backups and restore tests
  6. Amazon S3 User Guide: Locking objects with Object Lock. WORM model, retention periods, legal holds, governance and compliance mode, versioning
  7. Hetzner Docs: Object Lock, Retention. An S3-compatible service with Object Lock: it must be enabled when the bucket is created
  8. SNIA Dictionary (generated 28 April 2026): Write Once Read Many. WORM as storage that preserves what is written in an immutable fashion
  9. NIST glossary: air gap. Definition of an air gap
  10. LTO Program: Benefits of LTO. WORM cartridges from LTO-3, hardware encryption from LTO-4, tapes taken offline