Air-Gapped Backup with Storware: How It Works

Ransomware does not stop at production — backup data is a target in its own right, because an attacker who can reach and encrypt your copies removes your ability to recover. A dependable defense is to keep at least one copy that the backup system cannot freely reach or overwrite. This is what an air gap provides. Here is how Storware Backup and Recovery creates that separation between the node and your storage, and how the built-in backends differ so you can choose the right one.

The problem: constantly reachable storage is reachable by ransomware

A typical ransomware chain is straightforward: gain access, encrypt data, demand payment. If your backup storage is mounted and file-accessible from the node at all times, it sits in the same blast radius as everything else.

Two properties reduce that exposure, and they are not the same thing:

Immutability locks files so they cannot be altered or deleted for a defined period — in Storware, via the Immutable Backup option (Object Lock on object storage) or DD Retention Lock.
Air gap removes constant reachability altogether — the storage is not permanently attached to the node, so there is no always-open path to encrypt.

They are strongest together: an isolated copy that is also locked. This article focuses on the air-gap side.

The simplest gap: object storage and enterprise providers

The most direct way to create a boundary is to avoid file-based access in the first place. When Storware writes to object storage (S3-compatible, Azure Blob, Google Cloud Storage) or to a supported enterprise backup provider, the node has no direct file-system path of the kind ransomware typically abuses — and object storage adds Object Lock immutability on top. (docs: object storage)

File-system destinations are different: they are reachable by the node whenever it runs, so they benefit most from the explicit separation techniques below.

Built-in air-gap backends

Storware provides backends that mount storage only during a task (backup, restore, cleanup) and detach it afterwards — closing the window in which the data is reachable.

Rubrik Managed Volumes

Now documented under Enterprise Backup Providers, Rubrik Managed Volumes connect to your Rubrik environment and dynamically create a managed volume per protected entity (a VM, application, or storage instance). The volume is mounted over NFS only during backup, restore, and similar tasks — not continuously. Because Managed Volumes are snapshot-based, every change becomes a separate snapshot governed by the Rubrik SLA, giving you an extra recovery layer even if the node is reached mid-task. Storware sizes and grows the volume per entity automatically. (docs: Rubrik Managed Volumes)

Catalogic vStor

A second snapshot-based option that does what Rubrik Managed Volumes do, plus replication: each backup can create a new per-entity snapshot and, optionally, replicate it to a secondary vStor server. As with Rubrik, a per-entity NFS share is created and accessed only during sessions — with no need to pre-size the volumes. (docs: Catalogic vStor)

isoLayer (synthetic)

If you have a Linux host (Red Hat family works best) able to expose NFS shares, isoLayer creates the same per-entity separation over SSH: you provide SSH and NFS details, and Storware creates, attaches, and detaches shares per entity. It requires NFS 4.2 and a backend file system that supports ref-links (typically XFS). Unlike the two snapshot-based options, isoLayer supports synthetic backups — enabling instant restore and forever-incremental scenarios. Because it is not snapshot-based, pair it with the Immutable Backup feature so files cannot be removed or overwritten. (docs: isoLayer)

Bring your own storage: custom pre/post access scripts

Storware can separate the node from a backend it does not integrate with natively. In the file-system (synthetic and non-synthetic) destination settings, a pre/post access script hook runs your own mount/create and detach logic. The scripts are invoked across store, cleanup, connectivity-check, and restore tasks, so handle each context using the environment variables Storware exposes at invocation.

Because the mount runs as root while services run under the service account, grant the specific privilege in sudoers.d, for example:

%vprotect ALL=(root) NOPASSWD: /opt/vprotect/scripts/my-custom-bd/privileged.sh

Choosing a backend

Snapshot-based, minimal setup: Rubrik Managed Volumes (auto-sizing) or Catalogic vStor (adds replication).
Synthetic/instant restore on your own Linux: isoLayer — pair with Immutable Backup.
Simplest boundary, built-in immutability: object storage with Object Lock.
Unsupported backend: custom pre/post access scripts.

Where this fits

An air gap is one control inside a broader posture that Storware calls Data Protection Continuity — immutable copies, isolated copies, and verified recovery across multi-vendor environments. It empowers teams to keep at least one copy an attacker cannot reach or rewrite, with Platform Freedom rather than lock-in to a single storage vendor. (Immutable & Air-Gapped Backup Security)