1 Overview
A local backup is any copy of your data that lives on or near the system it protects. It might sit on a second internal drive, an external disk, a network share, or a small backup appliance in the same room. Local copies are valuable because they are fast. When a file is deleted by mistake or a database needs to be rolled back, a local copy usually restores in minutes rather than hours, and it does not depend on an internet connection or a cloud provider's availability.
The problem is that a local backup is only as trustworthy as its isolation. If the backup target is mounted, mapped, or reachable with the same credentials as the primary system, then anything that can damage the primary data can often damage the backup too. Ransomware, a destructive script, a careless administrator, or a compromised service account does not need to be sophisticated to reach a share that is always online. An air gap changes that equation by making the backup copy unreachable during normal operation.
This article explains why an air gap matters, what threats a local backup does and does not address, how to choose a strategy, how the 3-2-1 rule applies, why restore testing is the only real proof, and how offsite and encryption fit together. The goal is not to sell a product but to help you design a local backup that survives the incidents you are most likely to face.
2 What you are actually protecting against
It helps to separate the threats a local backup can handle from those it cannot. Accidental deletion, overwritten files, failed software updates, corrupted application data, and hardware faults are common and usually recoverable from a local copy. These are the everyday incidents that make fast local restores worth having. A local backup also shortens recovery when the primary system is simply unavailable and you need to keep working.
Ransomware and destructive attacks are different. Modern ransomware frequently searches for connected backup targets, deletes shadow copies, and encrypts or wipes any reachable repository before demanding payment. If your only local backup is a mapped drive with stored credentials, it is part of the blast radius. The same is true for a malicious insider or a compromised automation account. An air gap removes the path those threats rely on, so the backup remains intact even when the primary environment is fully compromised.
Physical and site-level risks are the other half of the picture. Fire, flood, power events, theft, and building access failures can destroy every copy in one location, air gap or not. That is why an air gap is necessary but not sufficient. It protects against remote and logical attacks, while offsite copies protect against physical loss. A mature design assumes both can happen and keeps at least one copy outside the primary trust domain at all times.
3 Choosing a backup strategy
Start with recovery objectives rather than technology. Decide how much data you can afford to lose, which sets your recovery point objective, and how long you can tolerate being down, which sets your recovery time objective. These two numbers drive how often you back up, what you back up, and how quickly you must be able to restore. A local air-gapped copy is usually the fastest restore path, so it should hold the data you need most urgently.
Next, decide what the local copy contains. Full system images let you rebuild a machine quickly, but they are large and change often. File-level and application-level backups are smaller and more flexible, but rebuilding a server from them takes longer. Many teams combine both: periodic full images for bare-metal recovery and more frequent incremental file or database backups for granular restores. The right mix depends on your RPO and RTO, not on a default setting.
Then design the air gap itself. Options include rotating removable drives that are physically disconnected after each backup, a backup appliance that only connects during a scheduled window, or a separate isolated network segment with no standing credentials from the production environment. Whatever you choose, the backup must be unreachable during normal operation, and the credentials used to write to it should not be usable to delete or encrypt it. Document the rotation schedule, who can access the media, and how the copy is verified after each run.
4 The 3-2-1 rule in practice
The 3-2-1 rule says keep at least three copies of your data, on two different types of media, with one copy offsite. An air-gapped local backup fits naturally into this model, but only if you count copies honestly. A primary dataset plus a snapshot on the same array plus a mapped drive in the same rack is not three independent copies. Independence is about failure domains, not file counts.
In practice, a workable arrangement is the production data as copy one, an air-gapped local backup as copy two, and an offsite or cloud copy as copy three. The two media types might be internal disks for production and removable or appliance-based storage for the local copy, with object storage or a remote site for the offsite copy. The air gap applies to the local copy, and the offsite copy should also be isolated so that a compromised production account cannot simply delete it.
Retention is part of the rule as well. Keeping many restore points locally improves your ability to recover from subtle corruption that is noticed weeks later, but it increases storage and management effort. A common pattern is frequent short-term local restore points, less frequent weekly copies, and longer-lived monthly or quarterly archives. The exact schedule should follow your stated RPO and any compliance obligations, and every retained copy should be tested at least occasionally. If a copy has never been restored, treat it as unproven rather than as protection.
5 Restore is the real test
A backup that has never been restored is a hypothesis, not a safeguard. The only way to know your air-gapped local copy works is to disconnect it from its normal role, bring it up in a controlled environment, and restore real data. That means restoring individual files, an application database, and ideally a full system, then verifying that the recovered data is complete and usable. A successful backup job log is not evidence of a successful restore.
Stress testing should include the awkward cases. Restore to different hardware than the original, because replacement equipment rarely matches exactly. Restore from the oldest retained copy, not just the newest, to confirm retention actually works. Restore while the production environment is unavailable, which is the realistic scenario. Measure how long each restore takes and compare it with your recovery time objective. If the measured time is longer than the target, the strategy needs to change before an incident forces the issue.
Testing also validates your documentation and your people. Someone should be able to follow written steps without the original author present, and the process should not depend on a single person's memory. Record what was restored, when, how long it took, and what problems appeared. Schedule tests on a recurring basis rather than once after deployment, because systems, data volumes, and staff change over time. An air gap protects the copy; restore testing proves the copy can actually bring you back.
6 Offsite and encryption
An air gap solves reachability, not geography. A disconnected drive in the same building still burns, floods, or gets stolen with everything else. At least one copy must live offsite or in a separate trust domain, whether that is a remote office, a colocation facility, or a cloud storage service. The offsite copy should be isolated as well, so that credentials stolen from production cannot be used to delete or overwrite it. Immutable or write-once retention settings can help enforce that separation.
Encryption protects the copies themselves. Data at rest on removable media, appliances, and offsite storage should be encrypted, and the keys should be managed separately from the backup data. If the encryption key is stored alongside the backup or is available to the same compromised account, the protection is largely cosmetic. Consider who can decrypt, where keys are held, and how recovery works if the key management system is unavailable. Losing a key is functionally the same as losing the backup.
Encryption also matters during transport. Copies moving between sites or into cloud storage should travel over encrypted channels, and the receiving side should verify integrity before the copy is trusted. Combine encryption with the air gap rather than treating them as alternatives: the air gap limits who can reach the copy, and encryption limits what they can do if they obtain the media. Together with an offsite copy and tested restores, they turn a local backup from a hopeful convenience into a dependable recovery asset.
7 Frequently asked questions
Is an external drive plugged in only during backups an air gap? It can be, if the drive is genuinely disconnected the rest of the time and the credentials used during the backup window cannot delete or encrypt existing restore points. A drive that stays connected, or that is reachable through a share with stored credentials, is not air gapped in any meaningful sense. The test is whether an attacker on the production network could reach and destroy the copy without physical access.
How often should the air-gapped copy be updated? That depends on your recovery point objective. If losing a day of data is acceptable, a daily rotation may be enough. If not, you need more frequent copies or a different design. Remember that each connection window is a moment of exposure, so balance recovery needs against the risk of leaving the copy reachable longer than necessary.
Do I still need offsite copies if I have an air gap? Yes. The air gap addresses logical and remote threats, while offsite copies address fire, flood, theft, and site-wide outages. The 3-2-1 rule exists because no single control covers every failure mode. Finally, how do I know the plan works? Test restores on a schedule, measure the results against your objectives, and fix the gaps you find. An untested air-gapped backup is still a lie, just a more expensive one.