Skip to main content
AirGapNetPhysical network isolation
← BlogEngineeringMarch 20268 min read

Air-gapped backups: when "immutable" is not enough

Storage-layer immutability slows down the attacker. A line that does not exist between backup windows stops them. The difference matters during a live incident.

Ransomware does not encrypt what it cannot reach. The defense is not 'can't be modified' — it is 'cannot be reached except for the backup write window'.

Section 01

What 'air-gapped backup' usually means

Most products that ship an 'air-gapped backup' SKU mean one of three things: an immutable retention policy at the storage layer, a separate tenant in a cloud backup service, or a tape rotation. All three are useful. None of them are an air gap in the physical sense.

The path between the production network and the backup target is up. The backup software walks down that path on a schedule. The credentials to write to the target are stored somewhere the production network can reach. An attacker who has the right tokens and enough time can corrupt the snapshot, change the retention policy, or replace the backup payload before the next restore test.

Section 02

Physical isolation of the target

A backup target that sits behind a hardware switch behaves differently. The path to the target is closed by default. During the scheduled backup window, the line opens, the backup software writes, the line closes. Outside the window, the production network has no route to the target — not because a firewall rule says so, but because the cable is electrically not connected.

An attacker with full production-network compromise during the closed state cannot reach the backup target to alter it. The 23 hours a day the line is down, the backups are not 'protected by policy' — they are physically out of reach.

  • Default-closed

    The line to the backup target is open only during the backup window the operator scheduled. Other 90% of the time it does not exist.

  • WORM still helps

    Combine with write-once-read-many storage on the target itself. Even during the window, the backup writes are append-only.

  • Restore is also a window

    Restore is a planned event, not a reachable service. The restore window opens the line on demand and closes it when the restore completes.

  • Per-target, per-schedule

    Multiple backup tiers can sit on their own AGN1, each with its own schedule. Daily target opens nightly; weekly target opens once a week.

Section 03

What this changes operationally

Backup jobs need to be scheduled rather than continuous. For most environments this is already the case — incremental snapshots run on a cron, not as a live mirror. The shift is that the line itself is on the same schedule as the job, and a missed schedule means the line stays down, not that the line stays up unused.

Monitoring also changes. The signal that matters is not 'did the backup write succeed' — it is also 'did the line open during the planned window, and did it close on schedule'. The relay log is the second half of the backup audit.

Section 04

What this does not solve

A backup that contains malware-laden content is still a backup of compromised data. The line being closed does not detect compromise — it only prevents tampering with the backup payload from the production side.

Combine physical isolation of the target with content-integrity checks on restore (signed snapshots, restore-time scanning, restore to a quarantined network for verification). The line keeps the attacker away from the vault; the integrity checks keep the operator from restoring the attacker's work.

Go from reading to running

See AirGapNet on your network.

We bring a real AGN1 to your bench and run one maintenance window on your equipment. 30 minutes on the call.