Air-Gapped Disaster Recovery — What to Replicate vs *Just Back Up*

Cloud DR guides assume *multi-region*. Air-gapped has *no regions*. A four-resource taxonomy and a redundancy strategy for each.

John Baek
John Baek
Founder, CollabOps
Air-Gapped Disaster Recovery — What to Replicate vs *Just Back Up*

Cloud DR guides assume multi-region. Air-gapped has no regions. You have separate racks in the same datacenter, or a second datacenter far away, or just backup tapes. Which goes where.

This post is a synthesis from five air-gapped customers. Four resource classes + a redundancy strategy per class.

Four resource classes

Resource class            | Redundancy cost | Loss cost
──────────────────────────┼─────────────────┼───────────
User data (PII, payments) | Very high       | Very high
Operational data (metrics, logs) | High        | Medium
Config / code             | Low             | Low
Ephemeral data (caches)   | 0               | 0

Each class gets a different DR strategy. Replicating everything at the same level explodes cost.

Strategy per class

User data — synchronous replication + separate site

High cost, high loss. Always synchronous-replicate to a separate datacenter.

Production site             DR site (separate datacenter)
─────────                   ────────────────────────────
Postgres primary  ← sync →  Postgres replica
                  RPO: 0
                  RTO: 5–15 min (manual failover)
                  RTO: 30 sec (auto failover, complex)

Air-gapped specifics — dedicated link between sites required. Encryption mandatory. Latency under 5ms recommended (sync replication degrades past that).

Operational data — async replication + same-site backup

Higher cost, medium loss. Async replicate to a separate rack in the same datacenter. Quarterly cold backup to a separate site.

RPO 5 min, RTO 1 hour. Some incident-analysis loss possible, but service stays up.

Config / code — git + build cache

Low cost. Mirror git to two locations. Build artifacts auto-backed-up to the internal registry.

Practically a DR baseline. Almost every org satisfies this naturally.

Ephemeral — just lose it

Caches, transient sessions, in-flight requests — lost during DR. Users retry.

Replicating these costs as much as user data. Accept the loss — that's the answer.

DR simulation — quarterly, mandatory

A DR design without simulation doesn't work. Force quarterly simulation.

Q1: deliberately down primary DB → failover to replica → verify → recover
Q2: cut all comms to production site → DR site activates → verify → recover
Q3: full restore from cold backup (selected systems) → verify
Q4: integrated — Q1 + Q2 + Q3 in one

Each simulation is half a day to a day. Without them, real-incident RTO is 5× the simulated RTO.

Cost table

Resource class         | Redundancy infra cost (monthly)
───────────────────────┼─────────────────────────────────
User data              | $4,000–12,000 (separate site)
Operational data       | $1,000–3,000
Config / code          | $200 (git mirror)
Ephemeral              | 0
───────────────────────┼─────────────────────────────────
Total                  | $5,200–15,200 / mo = $62k–182k / yr

The actual cost of air-gapped DR. 2–3× cloud DR — driven by dedicated links + separate sites + self-operations.

Fully replicate user data, nothing else

For SRE or infra leads designing DR for an air-gapped system, starting from a replicate everything assumption won't pass cost review. Fully replicating only user data and putting the other three classes at appropriate tiers — that's the realistic answer.

Tags#disaster-recovery#onprem#infrastructure#sre#devops