Deployment Guide

Introduction

AirGap for ObjectScale protects Dell ObjectScale object data by maintaining an isolated vault copy of production buckets. It uses a distributed, agent-based architecture with three components:

• The Object Copy Manager (the console) coordinates the work.
• Lightweight Object Copy Workers (copy agents) perform the S3 copy operations. They scale horizontally as data volumes grow.
• A vault agent orchestrates operations on the vault side.

Data flow is strictly unidirectional, from production into the vault. The vault is isolated from the production environment.

To protect data, you take these actions:

1. Select the buckets to protect from an automated inventory scan of the production cluster.
2. Organize the buckets into protection groups.
3. Attach a protection policy that handles scheduling, data sync, and load balancing across the copy agents.

Vault-side namespaces, buckets, and service accounts are provisioned automatically.

During initial replication, the vault operates in prep mode. Once the initial copy is established, the vault moves to a locked-down mode.

Configurable TPS rate limits govern sync activity against the production cluster. Replication therefore never degrades the performance of live application traffic.

info

Design principle: direction of trust. Nothing connects into the vault once vault mode is active. The vault agent polls the console, and all configuration, commands, and credentials ride back in the response. The vault firewall needs outbound rules only. The one exception is the prep-mode rule from the console to the vault management API (4443), which you remove at lock-down.

Prerequisites

Components at a glance

Component	Role	Delivery
Console (Object Copy Manager)	Management plane. Provides the web UI and REST API (HTTPS :443), orchestrates copy jobs, tracks sync state, and manages agent registration and upgrades.	Appliance image for VMware or Hyper-V
Copy agent (Object Copy Worker)	Reads from production ObjectScale and writes to vault ObjectScale. Scales out horizontally.	Java agent, customer-provided Linux host
Vault agent	Runs inside the vault network. Controls the physical air gap, commands the vault switch, and starts and monitors sync jobs.	Java agent, customer-provided Linux host

Sizing

The console appliance requires:

• 20 vCPU
• 100 GiB RAM
• 680 GiB of disk (four disks). The ClickHouse disk grows with the audit event rate.
• Datastore read and write latency below 5 ms on a 5-second rolling average

Copy agent hosts are sized by the number of concurrent copy jobs you need. Sizes range from an 8 GB host (2 concurrent jobs) up to a 64 GB host (13 concurrent jobs).

The vault agent host requires 8 vCPU and 32 GB RAM.

All VMs sync to NTP and run in UTC. Add NTP to your prerequisites.

Copy agent and vault agent hosts must run a systemd-based Linux (x86_64 or aarch64). Supported distributions are RHEL 8+, Rocky Linux 8+, Ubuntu 20.04+, SUSE/OpenSUSE, or any other systemd-based distribution.

The full requirements, including the sizing table for each JVM profile, are in Deployment Firewall & Port Requirements.

info

Sizing figures are planning averages only. Every environment is sized individually, based on data change rate and retention policy. Final sizing is confirmed during the services kickoff.

The console runs two databases of its own:

• PostgreSQL holds application state: jobs, settings, and agent registrations.
• ClickHouse holds high-volume analytics data: ObjectScale audit events and per-object copy logs.

ObjectScale version compatibility

The AirGap for ObjectScale management API integration has been validated against these versions:

Product	Version
Dell ObjectScale (OBS)	4.1.0.0
Dell ObjectScale (OBS)	4.2.0.0
Dell ObjectScale (OBS)	4.3.0.0
Dell ObjectScale (OBS)	4.4.0.0

No management API endpoints used by AirGap for ObjectScale have been removed or deprecated across any of these versions.

Network requirements

The Complete Port & Flow Matrix in Deployment Firewall & Port Requirements lists every flow, port, and direction your firewall team must permit. The component named as the source always initiates the connection.

Zone boundary	Rule
Vault to management plane	Allow outbound 443 from the vault agent and copy agents to the console, and 8443 (ClickHouse) from the copy agents.
Vault to storage	Allow outbound 9021 (HTTPS; 9020 only where policy allows unencrypted S3) from the copy agents to production ObjectScale (read) and vault ObjectScale (write). Allow 4443 from the vault agent to the vault management API.
Vault to air-gap switch	Allow 22 (SSH) or 443 (RESTCONF) from the vault agent to the switch. This flow is required: the switch is the air gap.
Console to production ObjectScale	Allow 4443 (management API), and 22 (SFTP/SCP audit-log collection) to every production node's management IP, never through a load balancer VIP. Audit-log collection is required.
Console to vault ObjectScale	Allow 4443 (management API) in prep mode only. Remove this rule at lock-down.
Inbound to console	Allow 443 from operator workstations and agents, and 8443 from the copy agents.
Inbound to vault	Nothing once vault mode is active. Keep all inbound rules to the vault network closed.

Once vault mode is active, no zone boundary requires an inbound rule into the vault. All vault traffic is initiated from inside the vault.

Accounts to prepare

Account	Where	Minimum privilege	Used for
Management API account (for example airgap-source)	Production ObjectScale	System Monitor and Namespace Administrator on the protected namespace. Namespace Administrator covers one namespace only, so System Administrator is required when you protect two or more namespaces.	Inventory scanning, and provisioning and rotating the per-namespace read-only S3 service account
Management API account (for example airgap-target)	Vault ObjectScale	System Administrator	Automated vault provisioning (namespaces, buckets, users, policies) and key rotation
SSH/SFTP account (for example airgap-ssh)	Production ObjectScale nodes (OS level)	Login and read-only access to the audit-log directory	Audit-log collection for change tracking
S3 service accounts	Production and vault ObjectScale	Created by the console when you click Create Service Accounts on Source Authentication.	Reading source objects and writing to the vault

Account notes

• Namespace Administrator is not inherited. When you protect a new namespace later, add the source account to that namespace's administrator list too.
• Credentials for the S3 service accounts must be stable. Rotate keys between sync windows.
• Use one correctly scoped account for each device. Never share an administrator credential across source and vault. The vault must be a dedicated cluster. Do not geo-replicate it with production.

Audit-log directory path

The audit-log directory path depends on the ObjectScale deployment type:

Deployment type	Path
Virtual deployment (default)	/var/log/vipr/emcvipr-object
Hardware appliance, including ObjectScale 4.x hardware appliances (EX and XF series)	/opt/emc/caspian/fabric/agent/services/object/main/log
Custom	The path configured on the device entry

warning

Grant read access to the audit-log directory explicitly. Some systems leave the directory world-readable, but hardened deployments are stricter. If access is missing, ingestion completes silently with zero records. Choosing the wrong deployment type for a hardware appliance has the same result: zero records, without an error.

Copy agent hosts

Copy agent hosts are customer-provided. Deploy one or more supported Linux hosts inside the vault network, sized as described in Sizing.

Make the hosts reachable before agent installation, with all routes from the flow matrix already open:

• Outbound to the console (:443).
• Outbound to ClickHouse (:8443).
• Outbound to the source and vault S3 endpoints (:9021 HTTPS; :9020 only where policy allows unencrypted S3).

You also need:

• The data-access endpoint DNS name or IP, including scheme and port (for example https://<host>:9021).
• The list of ObjectScale node IPs or hostnames for log collection.

Object Copy Manager Installation

The Object Copy Manager (the console) is delivered as an appliance image for VMware or Hyper-V. Deploy it on the production network, outside the vault, sized as described in Sizing.

Deploying the appliance

1. Import the appliance image into your hypervisor and assign it to the production network segment. In vSphere, use Deploy OVF Template. On Hyper-V, import the appliance image. See Compatibility Matrix for the supported hypervisors.
2. Power on the VM and allow the application stack to finish starting. First boot takes a few minutes while the internal databases initialize.
3. Browse to the console's web UI (HTTPS, port 443) from an operator workstation.
4. Replace the console's 443 and 8443 certificates with CA-issued certificates (TLS 1.2 or higher).

First boot and licensing

On first boot, the console runs as AirGap for ObjectScale R1 with no license installed. A license archive issued for this appliance turns on the licensed features and node-tier capacity.

1. Open Setup & Settings > Phone Home and copy the Appliance ID from the Appliance Identity section.
2. Send the Appliance ID to your account representative, along with your license redemption token.
3. On Setup & Settings > Licensing, choose the license archive (.zip) you receive and click Install License.

The navigation and available tabs update immediately to match the licensed product tier. No restart is required.

info

Vault Operations, the vault agent fleet, and mode transitions are available only on the R2 tier.

Object Copy Worker Installation

Object Copy Workers (copy agents) are standalone Java agents installed on customer-provided Linux hosts. Installation is a single command for each host.

Each agent connects back to the console over HTTPS and self-registers on first contact. Once registered, it appears in the console's Live Agents view and is immediately eligible to receive copy jobs.

Host prerequisites

Requirement	Details
Operating system	RHEL 8+, Rocky Linux 8+, Ubuntu 20.04+, SUSE/OpenSUSE, or any other systemd-based Linux (x86_64 or aarch64).
Network	Outbound HTTPS to the console (:443) and to the source and vault S3 endpoints (:9021 HTTPS; :9020 only where policy allows unencrypted S3), per the flow matrix.
Root/sudo access	Required for installation only. The installer creates a dedicated unprivileged argus-agent service user, and the agent runs as that user.
SELinux	Must be disabled before installation. Set SELINUX=disabled in /etc/selinux/config, then run setenforce 0. The installer checks and exits with instructions if SELinux is Enforcing.
Java 25.0.5	Pre-install Java 25.0.5 in the VM template. The installer checks only for Java 25 or newer, not for 25.0.5. Run java -version and confirm 25.0.5 before you install. The vault has no internet access, so this is the default path. If Java is missing or older, the installer downloads Amazon Corretto 25, which requires outbound HTTPS to corretto.aws.
Hostname	The agent's hostname must resolve to its interface IP address, not to a loopback address such as 127.0.1.1.
Time	The host syncs to NTP and runs in UTC.
Storage	Persistent storage for /opt/argus-agent/ and sufficient disk throughput for the expected copy load.

Installation steps

1. Generate an agent key. In the console, open the Agent Installation tab and click Generate Key.

   The key is a one-time registration token and is shown only once, so copy it immediately. If a registration fails, generate a new key and retry.

2. Run the installer. As root on the target host, run:

   curl -fsSL "<CONSOLE_URL>/api/agents/install.sh?type=copy-engine&key=<AGENT_KEY>" | bash

   Add -k only while the console still uses its default certificate, because -k turns the TLS check off. Replace the default certificate first (see Deploying the appliance).

   The script does the following:

   • Verifies Java, and installs Corretto 25 if needed (requires internet access).
   • Creates the argus-agent user and /opt/argus-agent/.
   • Downloads the agent JAR using the key.
   • Registers a systemd service with automatic restart, and starts it.

3. Verify registration. Switch to the Live Agents tab in the console. The new agent should appear with status ONLINE within 30 seconds.

Post-install configuration

After registration, assign the JVM profile that matches the host's RAM. See the sizing table in Deployment Firewall & Port Requirements, and Setup & Settings > Diagnostics > JVM Profiles in the console.

The agent restarts with the new settings automatically on its next update cycle. Software updates are operator-started: you start a copy agent upgrade from the console's Upgrade button. Vault agents upgrade from Vault Operations.

Scaling: adding additional copy agents

Copy agents scale out horizontally. To add copy throughput, repeat the installation steps on each additional host.

No coordination step is required between agents, because each registers independently with the console. A second agent on the same host is a manual setup: it needs its own install key, a systemd unit with ENGINE_PORT set (default 9091), its own data and log directories, and its own start-script paths. The installer takes no options, and running it twice overwrites the first install.

Vault agent installation

Vault agent installation is a separate flow from copy agent installation. Perform it from Vault Operations > Vault Agents > Install in the console, not from the Agent Installation tab used above.

1. (Optional) Set a console DNS name. Do this first on the Install tab if the console sits behind a load balancer or its IP may change.

   Vault agents installed with a DNS name keep working through console IP changes without re-registering. Leave it blank to use the current browser origin.

2. Generate a vault-scoped key. Click Generate Vault Key, give it a descriptive name (for example vault-agent-site-a), and copy the key immediately. It is shown only once.

   Vault keys are scoped so that they can authenticate only vault agent registration and sync endpoints. They cannot reach copy job endpoints or console settings.

3. Run the installer. As root on the vault agent host, run:

   curl -fsSL "<CONSOLE_URL>/api/agents/install.sh?type=vault-agent&key=<VAULT_KEY>" | bash

   Add -k only while the console still uses its default certificate.

   The script does the following:

   • Checks for Java 25. Pre-install Java 25.0.5 in the VM template, because the vault has no internet access.
   • Creates /opt/argus-agent/ and writes the agent config.
   • Registers a systemd service (argus-vault-agent), and starts it.

4. Verify registration. The agent appears on the Dashboard sub-tab once registered. It then discovers its assigned protection groups on its own and begins managing the incremental sync schedule and air-gap lifecycle.

The vault agent runs on its own Linux VM with 8 vCPU and 32 GB RAM. It uses the same supported operating systems as copy agent hosts. Its hostname must resolve to its interface IP address, not to a loopback address such as 127.0.1.1.

End-to-End Validation

Sync process flow

Use this flow as context when you validate the first sync.

1. Change tracking (continuous). The console ingests production ObjectScale audit events (creates, updates, deletes) into ClickHouse. It organizes them into fixed time windows for each protection group.
2. Window opens. On its locally held schedule, the vault agent commands the switch (ACD) to bring the air-gap port up.
3. Status check. The vault agent contacts the console (outbound HTTPS :443) and verifies system status. It then retrieves its assigned protection groups and pending sync windows.
4. Sync. Copy jobs run oldest-window-first. Copy agents read changed objects from production S3 (:9020/:9021) and write them to the vault ObjectScale. Per-object copy logs stream to ClickHouse (:8443) for full auditability.
5. Verification and close. When all windows complete, results are reported to the console. The vault agent then commands the air-gap port down. The vault returns to full isolation until the next scheduled window.

Sync schedules

A schedule policy defines a daily time window during which automated incremental sync jobs start. All VMs run in UTC, so window times are UTC.

Each policy sets:

• A start time.
• A window duration.
• How many days pass between runs.

Jobs start at a random time inside the window to spread the load.

Create and review policies under Cyber Vault > Source Data Protection Group Config > Sync Schedules. Then assign a policy to a protection group in Edit Group > Schedule Policy. The group's policy decides when its syncs run.

Creating your first protection group

1. Create the group. In the console, go to Cyber Vault > Source Data Protection Group Config and click Add Group. Set the following fields, then click Create Group.

   Field	Description
   Name	A unique name for the group.
   RPO (hours)	The target, from 1 to 168, used later for compliance reporting.
   Schedule Policy	Leave as Use default policy to inherit the global schedule.
   Target Vault Device	The vault-side ObjectScale device this group replicates to.
   Color	A tag for quick identification.

   A group's Target Vault Device must be set before the group can be provisioned (step 5). Groups with none set, including the built-in Default Group, show up disabled wherever a group is selected until one is assigned.

2. Assign buckets (wizard Step 1). Under Source Bucket Assign to Group, filter to unassigned buckets and select the ones this group will protect.

   Use the quick-select buttons (100 / 500 / 1000 / 2500) for fast bulk assignment, or individual checkboxes to hand-curate membership. A bucket can belong to only one protection group at a time. Click Assign.

3. Create the service accounts (wizard Step 2, Source Authentication). Open Service Account Configuration in the Cyber Vault navigation. On Source Authentication, select the namespaces and click Create Service Accounts.

   • The Source Authentication Service Accounts tab lists one read service account for each namespace on each source device.
   • The Target Authentication Service Accounts tab lists one write service account for each namespace on the vault device.

   The console creates these accounts when you click Create Service Accounts. Use Add Manually only for accounts you create yourself. While a vault is in vault mode, the vault agent controls the target accounts, and Rotate Key and Reveal Key are disabled.

4. Grant the source-side service account read access (wizard Step 3, ACL). Under Grant Cyber Vault Service Accounts Data Access ACL Policy to source buckets, select the source ObjectScale device. Filter to the group you just created, select all its buckets, and click Grant Access.

   This applies a read-access grant for the source-side service account on each source bucket. It merges into any existing bucket policy rather than replacing it. Without it, copy jobs fail with permission errors when they read from production.

5. Provision the vault target (wizard Step 4, Provision). Under Provision Namespaces and Buckets to Vault, filter to the new group and click Provision All Unprovisioned.

   In a single idempotent pass, the console creates everything a copy job needs to write to the vault:

   • The vault-side namespace.
   • A per-namespace service account and S3 keys.
   • The bucket itself.
   • A bucket ACL granting that service account read, write, and delete access.

   Confirm in the dialog and wait for the job to complete.

6. Create the protection policies (wizard Step 5, Policy). Under Source Data Protection Policy Config:

   1. Filter to the group and select the buckets (or Select All).
   2. Configure the Delete Sync toggle.
   3. Click Create Policies.

   One policy is created for each bucket, using the source and vault accounts that provisioning already registered.

   The read-only Mode badge (Prep or Vault) is inherited from the group's operational mode and cannot be changed for each policy. To move a group between modes, use Vault Operations > Vault Data Sync Dashboard > Switch to Vault Mode.

7. Start the first full copy. Creating a policy does not start a copy job by itself.

   1. Go to Full Data Sync Management and filter to the new group on the Vault Jobs sub-tab.
   2. Select the new policies and click Start Full Sync.
   3. In the Bulk Sync dialog, choose Standard as the Copy Mode to seed a brand-new, empty vault bucket.
   4. Confirm the distribution plan to dispatch the jobs. It shows how the jobs are spread across the registered copy agents.

   Smart Skip and Target Skip are for re-establishing the baseline or migrating from a prior deployment.

Verifying the first replication

1. Watch the copy progress. A newly protected bucket has no sync history yet. It does not appear on the Vault Data Sync Dashboard until its first changelist window is created.

   Until then, track progress from the Protection Policies tab. The Protection Status column moves from Unprotected to Protected.

2. Confirm coverage. Open Data Sync Reporting. Each chart shows one source namespace. The statuses mean the following:

   Status	Meaning
   Protected	The bucket has a completed full copy job.
   Retry Protected	Only a resumed job completed.
   Unprotected	No full copy has completed.

3. Confirm the vault side. On the Provision tab, toggle Vault Inventory to view the live vault-side inventory. Confirm that the expected namespaces and buckets are present.

4. Confirm RPO compliance. Open Group Health. The group's card should move from Unknown (no successful sync observed yet) to Compliant. The lag bar shows the time elapsed since the last successful sync, against the group's RPO target.

5. Confirm the air-gap cycle (vault-mode groups only). Open Vault Activity and confirm a matching Vault Open and Vault Close pair for the sync cycle, with a window duration in line with expectations.

   A Vault Open with no Vault Close within a reasonable time means the cycle stalled. Check that the assigned vault agent is still online before you escalate.

6. Test incremental changes. Add an object, delete an object, and add and delete an object within the same window on the production bucket. Run the sync and confirm the vault matches the source after each test.

7. Test the threat check. Raise a threat event before a sync and again during a sync. Confirm that the new sync is blocked in the first case, and that the running job finishes in the second.

8. Confirm the port on the switch. After each window, confirm on the switch that the air-gap port is down.

9. If a bucket does not clear, expand its row on the Vault Data Sync Dashboard to see its per-window job history. If a window shows a failed status, open the failed job's detail for the error log.

Locking down the vault

When the first full copy and the validation checks are complete, lock down the vault.

1. Configure the air-gap switch and ransomware detection.
2. Switch the protection groups to Vault Mode. Use Vault Operations > Vault Data Sync Dashboard > Switch to Vault Mode.
3. Remove the firewall rule that allows the console to reach the vault ObjectScale management API on 4443. Only prep mode needs this rule.

After lock-down, nothing connects into the vault.

See Also

• Deployment Firewall & Port Requirements, host requirements and the complete port and flow matrix
• Vault Agents, vault agent installation, dashboard, and communications