Most ransomware playbooks now include a step that targets backups before encryption begins. Once an attacker holds administrative credentials, an online backup repository that can be deleted or overwritten is simply another dataset to destroy. Two controls are commonly proposed in response: an air gap that separates the backup copy from the production network, and immutability that prevents the copy from being altered even by an administrator. They are often discussed as alternatives. They solve different problems.
The real question is which failure modes the organization must survive, how quickly it must recover, and how much operational burden it can carry. This article defines physical air gaps, logical air gaps and storage-layer immutability, sets out what each stops and what each does not, and describes the layered design most mature environments end up with.
An air gap is a separation between the backup copy and any system an attacker could reach from the production environment. In practice it covers two approaches.
A physical air gap places the copy on media that is not connected to anything: tape cartridges removed from the library and stored in a vault, removable disk shipped off site, or a system powered off between backup windows. While the media sits on a shelf, nothing can delete or encrypt it without a person physically handling it.
A logical air gap keeps the copy online but isolates it administratively and on the network: a separate network segment or site with restricted routing, a separate identity domain so production credentials grant nothing on the backup side, replication pulled by the isolated system rather than pushed from production, and connectivity opened only during scheduled replication windows.
Immutability means that once a backup object is written, it cannot be modified or deleted until a retention period expires. On S3-compatible object storage this is implemented with S3 object lock, a write-once-read-many (WORM) mechanism enforced by the storage system itself. In compliance mode, the lock cannot be shortened or removed by any user, including the storage administrator, for the duration of the retention period.
The critical property is where the control lives. A retention setting inside the backup application protects against mistakes in that application. Object lock at the storage layer protects against anyone who reaches the storage with valid credentials, because the storage refuses the delete regardless of who asks. Backup applications such as Veeam and Commvault write to object lock repositories natively.
An attacker with backup server credentials can issue delete commands to any repository those credentials reach. Immutability stops the deletion from succeeding. A logical air gap with separate credentials stops the commands from reaching the isolated copy at all. A physical air gap makes the copy unreachable, but only for media already offline; the most recent backups still on the library or staging disk remain exposed.
A malicious or coerced administrator is the case that distinguishes storage-layer immutability from most other controls. A logical air gap operated by the same person offers little protection. Compliance-mode object lock does, because no privilege on the system can override it before retention expires. A physical air gap also protects here, provided vault access requires a second person.
Malware spreading through network shares cannot reach media on a shelf, and a correctly configured logical air gap contains it. Immutability does not prevent malware from being written into new backups; it guarantees that clean restore points written earlier remain intact. Site loss is the reverse case: immutability on a single site does nothing against fire, flood or a regional outage, while an off-site physical copy or a logically isolated second site does.
Neither form of air gap detects bit rot; tape in a vault can fail unnoticed for years. Object storage with continuous integrity checking addresses this, and every design should include periodic restore testing regardless of the control chosen.
| Control | Protects against | Does not protect against | Recovery speed | Operational burden |
|---|---|---|---|---|
| Physical air gap (tape, removable media, powered-off vault) | Credential theft, malware propagation, insider deletion with dual control, site loss when stored off site | Recent backups not yet offline, silent media degradation | Hours to days for retrieval, sequential restore | High: handling, transport, vault, media refresh |
| Logical air gap (isolated network, separate credentials, pull replication) | Credential theft from production, malware propagation, site loss when at a second site | Insider with access to the isolated domain, misconfiguration, corruption of replicated data | Fast, online | Medium to high: standing second environment, identity and firewall maintenance |
| Storage-layer immutability (S3 object lock, compliance mode) | Credential theft, insider deletion, encryption of existing restore points, accidental deletion | Site loss on its own, malware written into new backups | Fast, online, direct to backup application | Low to medium: retention-aware capacity planning, time sync |
The common pattern is tiered. The primary backup target is an online, immutable object storage repository on premises, often configured as the hardened repository or capacity tier directly in the backup application. It receives every backup job, holds restore points under object lock, and serves the large majority of restores at disk speed.
Behind it sits an isolated copy for the last resort: a second immutable object storage system at another site behind a logical air gap, a tape export to a vault, or both. This copy is used rarely, so slower retrieval is acceptable. Suppose an organization must restore a 40 TB file server after an incident: it recovers from the local immutable tier the same day, while the isolated copy is held in reserve in case the primary platform itself was compromised.
The following is general guidance; regulatory requirements and recovery objectives should drive the decision.
Scality ARTESCA is S3 object storage built for backup, with S3 object lock providing immutability at the storage layer. In the tiered design described above it serves as the online immutable tier, handling day-to-day restores without waiting on media retrieval. Its object lock implementation and hardening measures are described on the security and cyber resilience page.
ARTESCA is validated with the major backup applications, including Veeam, Commvault, Cohesity, Rubrik, HYCU and Veritas, so the immutable repository is configured from the backup console. The current list is maintained on the backup compatibility page.
Because ARTESCA is available as software or as a hardware appliance from tens of terabytes upward, a second instance can be deployed at another site as the isolated copy, replicated over a controlled path with separate credentials. That gives immutability on both tiers and a logical air gap between them, with tape as an optional third layer.
Start by making the primary backup repository immutable at the storage layer, then decide how isolated the second copy needs to be based on the site-loss and insider scenarios the organization must survive.