How do you back up and restore an air-gapped AI system?

With the same discipline as any critical system, applied entirely inside the perimeter. An air-gapped AI system is backed up as versioned, hashed and signed copies of four things: the model weights, the document and embedding stores, the configuration and policies, and the audit ledger. Those copies stay on media that never leaves the controlled boundary, and they are proven by restore drills that are rehearsed rather than assumed.

The question matters in 2026 because sovereign AI deployments have moved into production, and production systems inherit business-continuity duties. Operational resilience regimes such as DORA, in force since 17 January 2025, treat recovery as something to be evidenced rather than asserted, and an air-gapped AI system faces the same question as any other critical service: if it were lost this afternoon, what exactly comes back, and how is that proven?

What exactly needs backing up?

Four stores, each with a different rhythm and a different consequence of loss.

• Model weights: large, static between versioned updates, and evidentially significant, because reproducing past behaviour requires the exact version that ran.
• Document and embedding stores: the fastest-changing component, and the one whose loss hurts daily operations most.
• Configuration and policies: access rules, retrieval scope and approval workflows, small in size and large in consequence.
• The audit ledger: the evidential record itself, and the one store where continuity, not just recovery, must survive the restore.

The binaries matter less than teams assume, because a sovereign system reinstalls from signed artefacts held inside the boundary. The four stores above are what cannot be recreated.

How does the 3-2-1 rule work without a cloud?

It adapts cleanly. Keep three copies of the data, on two different media types, with one copy held away from the primary site. The adaptation is what offsite means. It does not mean a cloud bucket, which would reopen the outbound path the air gap exists to close. It means a second controlled location under the operator's ownership, a sealed vault, or encrypted media moved under documented custody. The logic of the rule survives intact: no single failure, no single fire and no single mistake should be able to reach every copy.

How does the audit ledger stay continuous across a restore?

This is the distinctly sovereign part of the problem, because a gap in the ledger chain is an evidential problem, not just an operational one. Three disciplines keep it honest. The ledger is backed up on its own tighter cadence, because it is append-only and comparatively small. The restore event is itself sealed to the record, so a recovery is visible in the chain rather than hidden by it. And the chain verifies offline: on Mickai, a Sovereign Intelligence Operating System, the ledger is sealed under FIPS 204, the primary post-quantum digital signature standard, so an auditor can check continuity across the restore boundary without trusting the operator's word or our infrastructure.

How do you stop a tampered backup being restored?

By treating every backup as untrusted input until it proves otherwise. Copies are hashed at creation and signed, and the restore path verifies both before anything loads. Restore authority is separated from backup authority, so no single administrator can write a copy and silently make it the running system. And hardware-attested identity closes the loop: a restored system must re-attest before it rejoins service, so a restore onto substituted or compromised hardware is visible rather than silent.

Why must the restore path work fully offline?

Because a recovery that depends on an internet connection is not a recovery for an air-gapped site. Installation media, signed artefacts, verification keys and the documentation to use them must all exist inside the boundary and be tested from inside the boundary. A restore that begins by requesting a firewall exception has already failed its design, and a recovery plan whose first step is a download has not understood the deployment it claims to protect.

What recovery objectives should you set?

Honest ones, set per store rather than per slogan. Recovery point objectives differ naturally: document stores change constantly, weights change only at versioned updates, and the ledger should lose as close to nothing as its cadence allows. Recovery time objectives should come from measured drills on the organisation's own hardware, and we will not invent figures here, because the only honest number is the one a rehearsal produces. What can be said generally is that these objectives belong in the same governance record as every other continuity commitment, and that untested objectives are estimates, not commitments.

How do you know a backup actually works?

You restore it, on a schedule, onto standby or replacement hardware, and the drill ends only when the system serves real queries and the ledger verifies end to end. A drill that stops when the files have copied proves storage, not recovery. The full rehearsal proves the media is readable, the signatures verify, the keys are available, the people know the runbook and the timings are real.

“If you cannot demonstrate a restore, you do not have a backup, you have a hope.”

The perimeter and ledger disciplines this procedure leans on are set out at /sovereign-ai, and the film at /film shows the operating environment those backups protect.

Frequently asked questions

Can I keep an encrypted copy of our air-gapped backups in the cloud?

Doing so reopens the outbound path the air gap exists to close, and it makes recovery depend on connectivity and on a third party. Many operators choose a second controlled site or vaulted media instead. If a cloud copy is ever contemplated, it is an explicit, recorded risk decision, never a default.

How often should model weights be backed up if they rarely change?

At every versioned change, with periodic verification of existing copies against their recorded hashes in between. Weights do not need frequent copying, but stored media degrades silently, so the discipline for slow-changing stores is scheduled verification rather than scheduled duplication.

What happens to ledger entries written after the last backup if we restore?

Entries not yet copied are lost with the failed store, which is exactly why the ledger runs on its own tighter cadence than the bulk stores. The restore event is sealed to the record, so the boundary of any loss is visible and stated rather than hidden, and the exposed window is an engineering choice the operator can narrow.

Do restore drills mean taking the production system down?

No. Drills restore onto standby or spare hardware in an isolated segment of the same controlled boundary, exercising the identical path a real recovery would use. Production is untouched, and the drill still proves what matters: media, signatures, keys, runbook and timing.

Is tape a sensible backup medium for an air-gapped system?

Media choice is secondary to custody and verification, and offline-friendly media, including tape, fit an air-gapped design naturally. The 3-2-1 adaptation asks for two media types, so many sites pair disk for fast restores with tape or removable encrypted media for the vaulted copy.