An Air-gapped backup deployment fails most often not because the technology doesn’t work, but because IT Managers underestimate the planning required before the first backup job runs. Organizations that skip the planning phase typically discover their gaps during a recovery event—exactly when there’s no time to fix them. This guide provides a structured planning framework for air-gapped backup deployment, covering architecture decisions, hardware selection, update strategies, and the operational workflows that determine whether your isolated backup environment is genuinely reliable or just theoretically compliant.
This guide targets IT Managers responsible for designing and implementing air-gapped backup for the first time, or for organizations migrating from cloud-connected solutions to isolated deployments. Each phase builds on the previous one—work through them in order rather than jumping to hardware procurement before completing requirements documentation.
Phase 1: Requirements and Scope Definition
Before evaluating hardware or software, define exactly what needs to be protected, why isolation is required, and what recovery performance you need to deliver. These answers drive every subsequent decision.
Identify What Requires Air-Gapped Backup
Not every system in your environment necessarily requires an air-gapped backup deployment. Start by inventorying systems based on their data classification, compliance requirements, and business criticality. Systems that handle CUI under CMMC, systems subject to FISMA High impact controls, and systems containing data explicitly prohibited from cloud storage are clear candidates. Other systems may be better served by cloud backup or standard on-premises backup without the isolation overhead.
Document this inventory with the rationale for each system’s inclusion or exclusion from the air-gapped backup scope. This documentation becomes part of your compliance evidence and prevents scope creep that adds operational complexity without corresponding compliance benefit.
Define Recovery Objectives
Air-gapped backup introduces physical access requirements into the recovery workflow that cloud and standard on-premises backup don’t have. Define realistic Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each system category, accounting for these constraints:
- Physical access time: For backup storage in a secured or classified facility, factor in the time required to gain physical access during a recovery event, which may involve security clearance verification, escort requirements, or facility access procedures that don’t apply during normal business hours.
- Media retrieval for offsite copies: If your 3-2-1 backup strategy requires retrieving offsite media, factor in transport time and media handling procedures. Offsite retrieval in classified environments can take hours rather than the minutes required for cloud retrieval.
- Recovery bandwidth: Large-scale recovery from local storage is often faster than cloud recovery on a per-GB basis, but is constrained by local network bandwidth to the backup storage rather than internet bandwidth.
Document Compliance Requirements
Identify every compliance framework that applies to the systems in scope and extract the specific backup-related controls. For NIST SP 800-53, document the CP-9 controls and enhancements required at your system’s impact level. For CMMC, document the relevant practices from Domain 2 (Incident Response) and Domain 2 (Recovery). Create a controls matrix that maps each compliance requirement to the technical and procedural controls you’ll implement—this becomes your audit evidence framework.
Phase 2: Architecture Design
With requirements documented, design the backup architecture that meets them. Air-gapped backup architecture has fewer moving parts than cloud-connected solutions, but each component decision has significant operational implications.
Backup Server Placement
The backup server must reside within the isolated network segment—it cannot be placed outside the air gap and pull data in through a firewall. For most deployments, the backup server is a dedicated physical or virtual machine within the isolated segment running the backup server software. In environments with multiple isolated segments at different security levels, each segment requires its own backup server instance; cross-segment backup traffic is subject to the same controls as any other cross-segment data transfer.
Storage Architecture
Air-gapped backup storage typically combines disk-based and tape or removable media storage to satisfy both performance and long-term retention requirements. A common architecture uses disk-based storage for recent backups (meeting short-term RTO requirements) and tape or removable media for older backups that serve as the offsite copy. Size disk storage based on your retention policy and data change rates, not just current data volume—incremental backups accumulate, and retention periods in regulated environments are often longer than standard enterprise deployments.
Network Isolation Verification
Before deploying backup infrastructure, verify the isolation of the network segment through technical testing rather than relying solely on network documentation. Use network scanning tools within the segment to identify any unexpected connectivity paths, and document the isolation verification as part of your deployment record. For compliance purposes, the isolation must be demonstrable, not assumed.
Phase 3: Software Selection and Validation
Software selection for air-gapped deployment requires more rigorous evaluation than standard enterprise backup assessments. The key criteria are technical, not marketing-driven.
| Evaluation Criterion | How to Test | Pass/Fail Standard |
|---|---|---|
| Offline licensing | Disconnect from all networks; operate through one license cycle | Full functionality with no warnings or degradation |
| Zero call-home behavior | Deploy with network packet capture; review all outbound connections | Zero outbound connections to vendor infrastructure |
| Offline update support | Request self-contained update packages; test manual installation | Complete installation without internet access |
| Local storage targets | Verify support for local disk, NAS, and tape targets | All required storage types supported natively |
| Encryption at rest | Review encryption specifications; verify key management model | AES-256 with locally managed keys |
| Audit logging | Review log completeness; test log export to SIEM | All operations logged with tamper-evident output |
For organizations comparing software-only solutions against proprietary appliances, reviewing the TCO analysis for appliance vs. software-only air-gapped backup is worthwhile before finalizing hardware procurement decisions.
Phase 4: Hardware Procurement and Deployment
Hardware procurement for air-gapped backup should be sized for a 3-5 year operational period without major hardware replacement. Isolated environments can’t benefit from cloud elasticity, so right-sizing at deployment matters more than in cloud-connected architectures.
Backup Server Sizing
Backup server sizing depends on the number of endpoints, data volume, and backup window constraints. As a baseline for planning: allocate 4 CPU cores and 16GB RAM for every 50 endpoints being backed up, with additional resources for deduplication processing if enabled. Disk storage on the backup server should be sized to hold at least 30 days of backup data at your expected change rate, plus buffer for unexpected retention extensions. Undersizing the backup server is one of the most common mistakes in an air-gapped deployment, as adding capacity later requires bringing new hardware through the same procurement and deployment process.
Storage Capacity Planning
Calculate storage requirements using actual data rather than estimates. Run a data inventory across all systems in scope to determine total data volume, average daily change rate, and data types (which affects deduplication ratios). Apply your retention policy to calculate total storage needed, then add 30% overhead for growth and unexpected capacity needs. For tape-based offsite copies, determine the tape capacity and rotation schedule needed to satisfy both retention requirements and physical media handling logistics.
Phase 5: Update Strategy and Operational Workflows
The operational procedures that govern ongoing maintenance of an air-gapped backup environment are as important as the initial deployment. Without documented procedures, air-gapped environments drift out of compliance and into technical debt faster than cloud-connected alternatives.
Software Update Cadence and Process
Establish a formal update cadence—quarterly updates are a reasonable baseline for most environments, with expedited updates for critical security patches. Document the complete update process: sourcing the update package, verifying integrity, transferring through the air gap using approved media, and installing on the backup server and agents. Assign responsibility to a named individual or role, and log each update as a change record. The update process is an area where air-gapped environments accumulate risk if not actively managed—version drift makes troubleshooting harder and can create compatibility issues with endpoint agents running newer operating system versions.
Backup Monitoring Without External Connectivity
Standard backup monitoring tools that send alerts to cloud-based monitoring platforms or external email services don’t work in air-gapped environments. Plan for monitoring through internal channels: SIEM integration within the isolated segment, local alerting to on-premises email infrastructure, or scheduled log review by backup administrators. Define what constitutes a backup failure event that requires immediate response versus a warning that can be addressed during the next business day, and document the escalation path for each.
Recovery Testing Schedule
Schedule recovery testing at intervals that satisfy your compliance requirements and provide realistic confidence in recovery capability. For most frameworks, quarterly recovery tests of critical systems and annual full-environment recovery exercises are appropriate minimums. Document each test with the same rigor you’d apply to a real recovery event—actual times, actual procedures, any deviations, and any gaps identified. Recovery tests are also the mechanism for validating RTO achievability in your specific environment. The guidance on RTO and RPO planning for isolated environments provides additional methodology for structuring these exercises.
Phase 6: Documentation and Compliance Evidence
The final phase of deployment is documentation—creating the operational runbooks, compliance evidence, and architecture records that make the environment auditable and maintainable. Documentation is the difference between an air-gapped backup environment that grows more reliable over time and one that becomes increasingly difficult to manage as staff turns over.
- Architecture documentation: Network diagrams showing backup server placement, storage targets, and isolation boundaries. Hardware inventory with asset tags, serial numbers, and refresh dates. Software versions and configuration baselines for the backup server and all agents.
- Operational runbooks: Step-by-step procedures for daily backup monitoring, weekly capacity checks, monthly media rotation, quarterly software updates, and annual recovery exercises. Runbooks should be written at a level of detail that allows a qualified IT professional who has never worked with the system to follow them successfully.
- Compliance evidence portfolio: Controls matrix mapping compliance requirements to implemented controls, update logs, recovery test results, and access control documentation. Organize this evidence by control family so it can be provided directly to auditors during assessment.
Getting Your Air-Gapped Backup Deployment Right the First Time
A well-planned air-gapped backup deployment is significantly more reliable and less operationally demanding than a poorly planned one. The planning investment made before deployment pays dividends in reduced incident response time, cleaner compliance audits, and backup operations that IT teams can sustain without constant manual intervention.
The most common failures in air-gapped backup deployments—license validation issues, version drift, untested recovery procedures, and undersized storage—are all preventable with the planning framework described here. Work through each phase systematically, document as you go, and test recovery before you need it.
Zmanda Pro is designed for exactly this deployment model—software-only architecture that deploys on your hardware, offline licensing that eliminates vendor connectivity dependencies, and a management interface designed for isolated environments. To discuss your specific deployment requirements and get sizing guidance for your environment, schedule a consultation with our team. You can also explore Zmanda’s flexible backup deployment options to understand the full range of configurations available.
