Introduction

Delphix replication typically transfers data from a source engine to a target engine over a TCP network, with the source communicating directly with the target.

In some cases, compliance or security requirements prohibit direct network connectivity between engines. In these scenarios, offline replication (also called air gap replication) enables data transfer without a network connection.

Offline replication works by writing replication data to an NFS share from the source engine. Later, the target engine reads the data from the NFS share. At no point during this workflow do the two engines communicate directly.

In DCT, offline replication is configured through replication policies. Navigate to Data > Policies > Replication and select the Offline - Send Replication or Offline - Receive Replication mode when creating a policy. The DCT interface provides full support for creating and managing offline send and receive policies.

Prerequisites

To use offline replication:

  • Source engines must have an offline replication spec configured with the correct NFS share.

  • Target engines must have an offline receive spec referencing the correct NFS share and the unique tag of the corresponding send spec.

  • NFS shares can be distinct for send and receive engines.

  • CD engines access NFS shares as root, so the root user on each engine must have read/write permissions.

  • Offline replication stages data on the local database storage before transferring it to or from the NFS share, so enough free space must exist to accommodate the maximum size of the objects being replicated.

Limitations

  • NFS mounts only
    Currently, only NFS mounts are supported for air gap replication.

  • DCT support
    The DCT interface provides full support for creating and managing offline send and receive policies.

  • CD UI limitations
    The CD engine UI can display and update, but not create, offline send specs; offline receive specs are accessible only via CLI/API on the CD engine directly.

1-to-many and serialization points

Offline replication writes each initial or incremental update as a serialization point on the NFS share. The share is the only transfer path, so retention and ordering are critical.

1-to-many topology

  • A single offline send spec can feed multiple targets.

  • Each target creates its own receive spec pointing to the same NFS share.

  • As long as all updates remain on the share, every target can receive an identical data set by applying updates through the same serialization point.

Retention rules

  • The NFS share owner is responsible for cleanup.

  • If a required serialization point is deleted before a target receives it, the receive cannot be recovered or “fixed.”

  • Use getLastReceivedInfo to identify which directories are safe to remove.

Receive ordering

  • A receive job applies only the next single serialization point, even if newer ones exist.

  • If the source sends multiple times before the target receives, the target must run one receive per pending point to catch up.

Offline replication setup

Step 1: Create an offline send policy

Create an offline send policy by selecting a source Delphix Engine and the objects to replicate. Specify an NFS share for the policy.

Step 2: Create an offline receive policy

After you create the send policy, note the source replication tag. Specify this tag on the offline receive policy. The receive policy must be on a different engine than the source.

The send and receive policies can be executed manually or automatically on a schedule.

Monitoring and cleanup

Offline replication does not remove any data from the NFS share. It is your responsibility to clean up data on the NFS share after a successful receive.

To determine which directories are safe to delete, use the following endpoint: /delphix/replication/receive/{receiveSpecRef}/getLastReceivedInfo.

Example

ip-10-110-224-220 replication receive 'rcv-spec'> getLastReceivedInfo
ip-10-110-224-220 replication receive 'rcv-spec' getLastReceivedInfo *> commit
type: OfflineReplicationReceiveInfo
lastOfflineReceiveDataDir: f631d6f1-c62b-45c1-ba0c-385354d3410b/2
lastOfflineSerializationPointId: 2
lastSendTimestamp: 2025-08-15T23:23:25.252Z

Directory cleanup rules

  • Directories less than or equal to the last received serialization point (/1 and /2 in this example) are safe to delete once the receive job completes.

  • Directories greater than the last received serialization point (/3 in this example) must be kept for future receive.

A typical NFS share looks like this:

/nfs-share/
    f631d6f1-c62b-45c1-ba0c-385354d3410b/
        1/
        2/
        3/

  • /1 — safe to delete because it has already been received.

  • /2 — safe to delete because it is the last applied serialization point.

  • /3 — keep for a future receive.

Deleting replica namespaces

With offline replication, you must remove the offline replication receive spec before you can delete its replica namespace on the target engine.

Common questions

Do the source and target engines ever connect over the network?

No. Offline replication is designed so that neither engine is aware of the other. Both interact only with the specified NFS share.

How do I know when it's safe to clean up the air gap server?

Use the getLastReceivedInfo endpoint shown above for the relevant offline receive spec.

Last updated
Oct 8, 2026