Backups are a primary target in destructive attacks because recovery leverage disappears when copies are encrypted, deleted or made inaccessible. An isolated backup design aims to preserve recoverability by limiting when production systems can reach backup infrastructure and by separating administrative authority from ordinary user and server credentials.
Isolation is more than unplugging a cable after a job. A usable architecture defines how data enters, who can manage retention, how integrity is checked and how clean systems reconnect during recovery. The goal is a repeatable operating model that remains secure on an ordinary Tuesday and understandable during a crisis.
Key takeaways
The short version
- Separate backup data transfer, administration and recovery access as distinct trust paths.
- Keep the data path available only for the time needed by the approved job where technically feasible.
- Use immutable or protected retention and independent credentials in addition to network isolation.
- Prove the design through restoration exercises and documented clean-room procedures.
Start with recovery requirements
Recovery point and recovery time objectives determine how frequently data must move and how quickly systems must be available. A daily physical connection may work for one workload but fail a database that can tolerate only minutes of data loss. Classify workloads before choosing a common pattern.
Also define the threat scenarios. Ransomware using production credentials, a compromised backup administrator, malicious deletion and site loss require different safeguards. Isolation can reduce production-to-backup reachability but cannot by itself protect against a privileged insider or a compromised management plane.
Separate the three paths
The data path carries backup content. The management path changes policies, retention and credentials. The recovery path returns data to clean systems. Treating all three as one broad network connection gives an attacker more options than necessary.
Where the platform supports it, use dedicated interfaces, identities and zones. Allow backup agents to send only the required traffic, prevent production accounts from administering the repository and require a deliberate procedure before restoration access is opened.
Create a controlled transfer window
A disconnected-by-default path can be enabled shortly before the backup job and removed after completion and verification. Schedule enough time for retries and monitoring, but do not leave the path open merely because the next job will run later. The window should have an owner, expected endpoints and an automatic or supervised closing condition.
AIRGAPNET can physically control the Ethernet path for this pattern. The backup software still needs authentication, encryption, access restrictions and monitoring while the connection exists. If jobs require continuous replication, immutable storage or one-way transfer may be more suitable than periodic isolation.
Protect integrity and retention
A successful transfer does not prove that the backup is safe. Use platform features such as immutability, object lock, retention controls and independent deletion approval where available. Encrypt data and protect keys separately. Monitor unexpected volume, retention changes and failed verification jobs.
Keep more than one copy and avoid a single technology or credential boundary. CISA recommends offline encrypted backups and regular availability and integrity tests. An isolated network contributes to that strategy, but media diversity and off-site resilience address failures that network controls cannot.
Engineer the recovery process
Document how the organisation establishes a clean recovery environment, obtains trusted installation media, restores identity services and validates data before reconnecting production. Recovery credentials and configuration documentation should remain available even when the main directory or password manager is unavailable.
Exercise the entire chain. Include approval of the physical path, repository access, restore performance and the decision to reconnect recovered systems. Capture measured recovery times and correct the design when assumptions do not survive the test.
A simple reference pattern
One practical pattern places production agents in a restricted source zone and the repository in a separate backup zone. A dedicated transfer path is opened for a scheduled job, while management remains accessible only from a hardened administration workstation through a different route. The repository enforces retention independently of production credentials.
After the job, the system verifies completion, records the result and removes the transfer path. A secondary copy remains outside the same credential and location boundary. Recovery uses a clean zone that is not directly exposed to the compromised production environment. Products and protocols vary, so treat this as a design prompt rather than a universal blueprint.
Document capacity assumptions as well as security ones. Transfer volume, verification time and retry behaviour determine how long the path must remain available and whether the window can close safely after a partial job.
Decision checklist
Questions to resolve before implementation
- Map recovery objectives and backup frequency for each workload tier.
- Separate data, management and recovery paths and identities.
- Define connection windows, owners, endpoints and closing conditions.
- Use protected retention, encryption and independent deletion controls.
- Maintain more than one copy across appropriate media or locations.
- Run full restoration exercises and record measured recovery outcomes.
Common questions
Questions teams ask first
What is the difference between an offline and immutable backup?
An offline backup is not reachable through a network path. An immutable backup cannot be changed or deleted during a defined retention period. They address different risks and can be combined.
Can backup jobs run through a temporary physical connection?
Yes, when the platform tolerates scheduled windows and the process reliably opens, monitors and closes the path. Continuous replication or very short recovery-point objectives may require another architecture.
How often should restores be tested?
There is no universal interval. Test according to business impact, change rate and regulatory obligations, and include both representative file restores and full service recovery. A backup that has never been restored is an unverified assumption.
Official references