A ransomware event becomes a business continuity crisis the moment attackers reach the backups. That is why an air gapped backup for ransomware is not an optional storage feature. It is a recovery control designed to preserve a clean copy of your data when production systems, administrator accounts, and connected backup repositories can no longer be trusted.
For a law firm, accounting practice, or MSP, the stakes are immediate. Missed filing deadlines, inaccessible client records, unavailable line-of-business applications, and a public disclosure of compromised data can cost far more than the ransom demand. The question is not whether you have backups. It is whether you can restore them after an attacker has had time to find, encrypt, delete, or corrupt everything connected to your environment.
Why connected backups fail during ransomware
Modern ransomware operators do not stop at encrypting a file server. They conduct reconnaissance, steal credentials, disable security tools, and look for backup consoles and storage targets. If the backup platform shares identity systems, network access, or privileged accounts with production, it may be within reach before anyone realizes an intrusion is underway.
This is why a nightly backup job alone is not a recovery strategy. A backup can report as successful while the recovery path is weak. An attacker may delete restore points, shorten retention, encrypt the repository, alter job settings, or steal data from the backup set for extortion. Any organization that assumes its cloud backup is automatically isolated should verify how administrative access, deletion protection, replication, and recovery credentials actually work.
Air gapping addresses a specific failure point: attacker access. The protected copy is separated from the production environment so that a compromised server or administrator session cannot directly alter it. That separation may be physical, logical, or operational. What matters is whether the control remains effective when the primary environment is under attacker control.
What an air gapped backup for ransomware should include
A true air gap is often described as offline storage, but the practical design is more nuanced. Completely offline media can offer strong isolation, yet it may not meet the recovery-time needs of a firm that must restore critical applications within hours. Many businesses need a layered design that combines fast local recovery with protected offsite copies.
A defensible architecture generally separates production, backup management, and protected recovery storage. It also uses encryption, strict identity controls, retention rules that cannot be casually changed, and a documented process for restoring systems into a clean environment.
The key controls work together:
- Immutable retention prevents backup data from being modified or deleted for a defined period, including by privileged users under normal operating conditions.
- Network or operational isolation limits when and how the protected repository can communicate with production systems. A copy that is always mounted and broadly reachable is not meaningfully air gapped.
- Separate credentials keep backup administration independent from everyday domain administrator accounts. Multifactor authentication should protect every privileged path.
- Encrypted offsite copies protect data confidentiality while giving the business a second recovery location if the primary site, hardware, or local repository is unavailable.
- Tested recovery procedures prove that the organization can locate a clean restore point, rebuild essential systems, and return users to service within an acceptable timeframe.
The right mix depends on your recovery objectives. A small accounting firm may prioritize rapid restoration of tax software, file shares, and email archives during tax season. An MSP may need tenant-aware controls, delegated visibility, and separate recovery boundaries across multiple clients. A financial services organization may need retention, encryption, and audit evidence that support its compliance obligations.
Immutable is valuable, but it is not the whole answer
Immutability is a critical ransomware defense because it makes destructive changes harder or impossible during the retention window. But immutable storage is not identical to an air gap. If an attacker can access the backup console, expose data, change future backup policies, or compromise the systems required to restore, the business still has material risk.
Treat immutability as one layer of recovery assurance. The stronger design also limits management-plane access, separates roles, protects credentials, monitors suspicious administrative actions, and preserves recovery documentation outside the affected environment.
There is a trade-off. More separation can add complexity, retrieval time, and operating cost. Those costs are reasonable when compared with the cost of rebuilding an environment from scratch, but the design must match the organization. Overengineering a recovery process that staff cannot operate under pressure is not a win. The goal is controlled recovery, not security theater.
Build for recovery, not just backup completion
A backup report tells you that data was copied. It does not tell you that the data is usable, complete, clean, and recoverable within the business deadline. Recovery planning starts by identifying the systems that keep revenue and client commitments moving.
For most organizations, those systems include identity services, core applications, databases, file shares, email data, virtual machines, and configuration records for firewalls and network equipment. Do not overlook SaaS data, endpoint data, and the credentials or encryption keys required to access the restored environment. The dependency chain matters. Restoring an application before its database, authentication service, or license server is available can extend downtime unnecessarily.
Define recovery time objectives and recovery point objectives in business terms. Ask how long each system can be unavailable and how much data loss is tolerable. A payroll system may require a more recent recovery point than archived client files. A virtual desktop environment may need to be restored quickly so a distributed workforce can continue operating, while lower-priority data can return later.
Then document the recovery order and assign owners. During an incident, ambiguity creates delay. Your team should know who can authorize a restore, who has access to the protected platform, where recovery credentials are stored, how clean systems will be staged, and how restored data will be validated before users reconnect.
Test the gap before an attacker tests it
Quarterly recovery testing is where backup confidence becomes operational evidence. Tests should go beyond restoring a single file. Restore representative virtual machines, databases, and application data into an isolated environment. Verify that users can authenticate, records open correctly, applications run, and critical workflows complete.
A useful test also measures elapsed time. If your stated objective is to restore core operations in four hours, record how long it takes to identify the restore point, provision infrastructure, transfer data, validate systems, and release users. The result may reveal a bottleneck in storage throughput, network capacity, licensing, DNS, or staff access that no dashboard will expose.
Clean recovery points deserve special attention. If attackers were present for weeks before encryption, restoring the most recent backup could reintroduce compromised accounts, malicious scheduled tasks, or altered configurations. Your incident response process should help determine the likely intrusion window and select a restore point accordingly. In some cases, a clean rebuild paired with data restoration is safer than bringing back a full system image.
Operational ownership closes the recovery gap
Air-gapped designs fail when they are treated as a one-time project. People change roles, vendors change platforms, applications are added, retention requirements shift, and privileged accounts accumulate. Recovery controls need regular review just like firewalls, endpoint protection, and access management.
That means reviewing backup job coverage, failed jobs, retention status, immutable-lock settings, administrative access, encryption-key custody, and test results on a defined schedule. It also means ensuring leadership receives a plain-language view of recovery readiness: what can be restored, how quickly, when it was last tested, and what gaps remain.
For organizations without a large internal infrastructure team, managed backup and disaster recovery can provide the operational discipline that is otherwise difficult to maintain. Xaccel designs protected recovery around encrypted backups, separated access, documented recovery procedures, and tested outcomes because a backup that cannot be restored on time is simply stored risk.
The practical standard is clear: keep one or more recovery copies outside an attacker’s reach, verify that they are usable, and rehearse the decisions required to restore the business. When ransomware strikes, certainty comes from a recovery process your team has already proven.