1 Overview
Backup software is often sold as the solution to data loss, but software alone cannot protect you from the threats that actually destroy backups. Ransomware, insider misuse, and administrative mistakes routinely reach the same systems that hold your recovery copies, because those copies live on the same network, use the same credentials, and depend on the same management plane. When an attacker compromises an administrator account, every repository that account can reach becomes a target, including the backups you were counting on.
The missing ingredient is an air gap: a deliberate separation between production data and at least one copy that cannot be reached, altered, or deleted through normal network access. That separation can be physical, such as removable media stored offline, or logical, such as an isolated vault with one-way transfer and immutable retention. The goal is the same in both cases. Even if every online system is compromised, one trustworthy copy survives.
This article explains what an air gap protects against, how to choose a strategy that fits your recovery objectives, how the 3-2-1 rule works in practice, why restore testing matters more than backup success reports, and how offsite storage and encryption fit together. It avoids vendor names and product claims, focusing instead on principles you can apply with whatever tooling you already own.
2 What you are actually protecting against
Most backup failures are not caused by disk hardware dying. They are caused by threats that also target the backup infrastructure. Ransomware operators commonly search for backup servers, catalog databases, and credential stores before encrypting production systems, because destroying recovery options removes the victim's leverage. If your backup server authenticates with domain credentials that an attacker has already stolen, your backups are effectively online and exposed.
Accidental deletion and administrative error are equally common. A script with a wrong path, a retention policy applied to the wrong job, or a storage array reinitialized during maintenance can erase copies that were never tested. Insider threats, whether malicious or careless, follow the same pattern: anyone with legitimate access to the backup console can often delete or overwrite data without triggering an alert.
Natural and infrastructure events add another layer. Fire, flood, power failure, theft, and extended cloud outages can take out an entire site, including local backup appliances. An air gap addresses the common thread in all these scenarios: it ensures that at least one copy is not reachable through the same channels an attacker or mistake would use. That copy may be slower to restore, but it remains available when everything else is not.
3 Choosing a backup strategy
Start with recovery objectives rather than products. Decide how much data you can afford to lose, expressed as a recovery point objective, and how long you can tolerate being down, expressed as a recovery time objective. These two numbers drive almost every other decision, including backup frequency, media type, and whether you need continuous replication or periodic snapshots. A system that can be rebuilt in an hour needs a different strategy than a database that must be restored to the last committed transaction.
Next, classify data by criticality and change rate. Static archives, configuration files, and reference data may only need periodic copies, while transactional systems need frequent, consistent snapshots. Group workloads so that retention and scheduling policies are manageable rather than one-off. Document which systems depend on each other, because restoring a database without its application configuration or identity store rarely produces a working service.
Finally, design for failure of the backup system itself. Avoid a single repository, a single credential, and a single management server. Separate the accounts used for backup administration from everyday administrative accounts, and require additional approval or multi-person control for deleting retention. A strategy that assumes the backup infrastructure is always healthy will fail precisely when it is needed most.
4 The 3-2-1 rule in practice
The 3-2-1 rule states that you should keep at least three copies of your data, on two different types of media, with one copy stored offsite. In practice, the third copy is where the air gap belongs. Two copies on the same storage platform, even in different folders or arrays, share the same failure modes and the same attack surface. The offsite copy should be isolated enough that compromising production does not automatically compromise it.
Implementing this means deciding which copies are online, which are nearline, and which are offline. Online copies support fast restores for routine incidents. Nearline copies, such as a separate repository with restricted credentials, add resilience against local failures. The offline or air-gapped copy is your last resort, and it should be written in a way that cannot be modified or deleted remotely, whether through removable media, a one-way transfer, or immutable retention with a separate administrative boundary.
Rotation matters as much as existence. If the same removable drive is always connected, it is not really air-gapped. Establish a schedule for rotating media, verifying that each rotation completed successfully, and storing the offline copy in a location with appropriate physical controls. Test that you can read the offline copy without relying on the production network, because an air gap that cannot be restored from is only a comforting idea.
5 Restore is the real test
A successful backup job proves only that data was written somewhere. It does not prove that the data is complete, consistent, or restorable within your recovery time objective. The only meaningful measure is a restore that produces a working system, performed under conditions similar to a real incident. Schedule restore tests regularly, and treat failures as incidents with owners and remediation deadlines.
Test at multiple levels. Recover individual files to confirm that permissions and metadata survive. Recover an entire virtual machine or database to confirm that the application starts and passes integrity checks. Recover from the air-gapped copy specifically, because it uses different media, different transfer methods, and often older procedures than your daily restores. Measure how long each step takes and compare it with your stated recovery time objective.
Stress testing means adding realistic pressure. Restore without the help of the person who built the system, using only documented procedures. Restore during business hours when production is busy. Simulate the loss of the primary backup server so that you must rely on the offline copy. Document what broke, update the runbook, and repeat. Encryption belongs in this testing too: confirm that you can retrieve keys and decrypt data when the normal key management service is unavailable, because encrypted backups without accessible keys are indistinguishable from no backups.
6 Offsite and encryption
Offsite storage protects against events that destroy an entire location, but distance alone is not enough. The offsite copy must also be isolated from the credentials and networks used in production. A replicated repository that trusts the same identity provider as the primary site can be encrypted or deleted along with everything else. Prefer a separate trust boundary, separate administrative accounts, and, where possible, a transfer method that only allows data to move in one direction.
Encryption protects data in transit and at rest, which matters for removable media, cloud storage, and any copy that leaves your physical control. Use strong, well-reviewed encryption and manage keys separately from the encrypted data. Store recovery keys in a secure location that is itself backed up and accessible during a disaster, and document who can retrieve them. Avoid shared keys across unrelated systems, and rotate them when staff or roles change.
Balance security with recoverability. Encryption that depends on a single service, a single person, or a single hardware token can become a single point of failure. Test decryption as part of your restore drills, including scenarios where the primary key store is offline. The combination of an air gap, offsite placement, and tested encryption gives you a copy that survives both attacks and accidents while remaining usable when you need it most.
7 Frequently asked questions
Is an air gap the same as offsite storage? Not necessarily. Offsite storage places a copy in a different location, but that copy may still be reachable over the network with the same credentials. An air gap adds isolation so that production compromise does not automatically reach the copy. The strongest designs combine both: an offsite copy that is also offline or immutable.
How often should I rotate offline media? It depends on your recovery point objective and how much data you can afford to lose between rotations. More frequent rotation narrows the gap but increases handling and the chance of human error. Whatever schedule you choose, verify each rotation and keep a log so you know which copy holds which point in time.
Can cloud storage be part of an air-gapped strategy? Yes, if it uses immutable retention, separate credentials, and a trust boundary that production cannot cross. Object lock and versioning can prevent deletion, but they must be configured and tested. Without those controls, cloud storage is simply another online copy.
Do I still need backups if I replicate data? Yes. Replication copies changes, including corrupted or encrypted changes, and does not provide point-in-time recovery. Backups with retention let you go back to a known good state. Finally, how do I know my backups work? Only by restoring them, including from the air-gapped copy, on a schedule you can sustain.