Storage

This tab configures the Dell ObjectScale storage devices that the console collects audit events from or copies data to.

Overview

Storage devices are the sources and targets of all data movement in the system.

• Source devices feed the audit event pipeline.
• Vault devices are the write targets for Cyber Vault copy operations.

Bucket Groups and Sync Schedule Policies are managed under Cyber Vault > Source Data Protection Group Config, including Sync Schedules. Vault target S3 credentials are provisioned automatically per namespace during Cyber Vault setup.

ObjectScale devices

Each entry is one Dell ObjectScale array. The system either ingests audit logs from it (source) or copies data to it (vault target).

Devices are listed in the Registered Devices table at the bottom of this section.

Registered Devices table

Column	Description
Device Name	The display name entered in the device configuration.
Type	Source (blue) for audit-ingest devices. Vault (purple) for Cyber Vault copy targets.
IPs / Endpoint	The device's node IPs, the first two and then +N, for source and vault devices alike. The management endpoint URL is shown only when no node IPs are set.
Version	The detected ObjectScale software version. See below.

The Version column shows:

• A green badge immediately after a successful Test Auth run.
• A gray badge for the previously detected version, kept across sessions. Hover over it to see when the version was last tested.
• — if the version has never been detected.

Click Edit to expand the device configuration inline. Click Delete to remove the device.

Federation (geo-replicated clusters)

When a source device's Management API is configured, the console asks that ObjectScale system for the list of VDCs (sites) in its federation. Every VDC in a federation knows all the others, so registering one cluster is enough to discover its peers.

• Federation column. It shows Federation · N VDCs. When some VDCs of the federation are not registered yet, it also shows (N not added) in red and a small + <VDC name> button for each of them. Devices of the same federation are grouped in the table under a colored ECS Federation header.
• "Part of an ECS federation" banner. It appears in the device configuration in amber. It lists each VDC that is not registered, with Add this VDC. When every VDC is registered, the banner turns green and reads ECS federation active.

How a VDC is matched to a registered device

A VDC counts as registered when any of its management addresses equals any address of a registered source device. The addresses of the device are its Management Host and its Node IPs. The scheme and port are ignored, and upper or lower case does not matter.

A multi-node VDC reports one address per node, for example 192.0.2.11 through 192.0.2.18. A device registered with only the first node's address, or with all eight, is recognized either way.

Vault devices are never counted as federation members, even when a federated VDC is also used as the vault.

What "Add this VDC" fills in

It creates a new source device named after the VDC, marked Federation audit peer. Its audit is collected and its buckets are not inventoried a second time. Its own nodes are still collected for licensing. See the node_inventory step under Run Inventory Scan.

Field	Value
Node IPs	Every node address of the VDC, so audit logs are collected from all nodes.
Management Host / IP	The VDC's first address. The username and port are copied from the device you discovered it from.
S3 data endpoint	A suggestion: the discovering device's endpoint with the host replaced by the VDC's first address. Check it with Test, or replace it with the site's load balancer.

You only enter the passwords, which are never copied. Then click Save.

Automatic repair of address lists

A multi-node VDC's whole address list stored as one node IP, such as 192.0.2.11,192.0.2.12,..., makes SSH ingest fail with UnknownHostException for that device.

The console splits such entries into separate node IPs when settings are loaded or saved. It uses the first address if a Management Host or S3 data endpoint holds a list.

Open the device and click Save once to write the repaired values to disk. The backend log shows a node IP list ... repaired line.

Delete and purge a device

Removing a device is a two-stage process, so that historical jobs and audit records keep resolving.

Delete (soft delete)

Delete hides the device from the Registered Devices table and from every device picker in the product. These include:

• The Target Vault Device and source-device dropdowns on the group and wizard forms.
• The bucket-browser device filter.
• The source and target authentication screens.

The device's UUID and all of its linked records are preserved: vault configs, protection groups, jobs, and audit history. Soft-deleted devices are shown separately below the table as a Deleted Devices count.

Restore

You can restore a soft-deleted device from the Deleted Devices list. It returns to the Registered Devices table and the pickers.

If settings.json was wiped, Restore re-creates the device from the registry with its original UUID. You must re-enter its credentials.

Purge (permanent and irreversible)

Purge fully removes the device and cleans up everything that referenced it.

Scope	What is removed
Configuration and operational state	Bucket inventory, protection groups (their member buckets are unassigned, not deleted), copy policies (vault configs), the Vault Device Management record and its health history, target-auth ownership, pending key rotations, pending namespace provisions, access-key tracking rows, ingest offsets, and the incremental-copy caches.
ClickHouse audit data	The device's ingested audit events and its ingest offsets are wiped.
Remote de-provisioning (best effort)	The source read-ACL bucket policies the console applied are reverted. The customer's original policy is restored where one existed. The ObjectScale service accounts the console created on the device are deleted.
Preserved	Job history is kept, meaning the Jobs list and per-job copy logs. Past activity stays auditable.

If the device's cluster is unreachable, for example because it was decommissioned, the remote steps are skipped with a warning and the local cleanup still completes.

Before purging, the confirmation dialog shows a reference-count summary of exactly what will be removed.

Purge is refused in these cases:

• An audit ingest is running for the device. Stop the ingest first.
• A purge for that device is already in progress.

warning

Purge cannot be undone.

Purge runs as a reviewable job

When you confirm, the cleanup starts as a Device Purge job that runs in the background. The confirmation shows the job number, and the device stays in the Deleted Devices list until the job finishes.

Open System Jobs to follow the per-stage steps:

1. Resolve
2. Ingest guard
3. ACL revert
4. Service-account deletion
5. ClickHouse audit purge
6. PostgreSQL cascade
7. Settings strip
8. Registry removal

Afterward, you can confirm exactly what was removed and that job history was preserved. Because purge runs as a job, the dialog does not wait while the console tries to reach the device. For a decommissioned cluster, that attempt times out.

Device configuration fields

Fields marked with an asterisk (*) are mandatory. The Save Settings button is disabled until every registered device has all required fields filled in. Empty required fields are highlighted with a red border.

Field	Description
Device Name *	A short label used throughout the UI and in audit event records. Renaming a device does not affect existing records, because events are matched by device identity, not display name.
Node IPs *	The ObjectScale data node IP addresses or DNS names, one per node. Separate them with commas. Spaces, semicolons, and line breaks also work, and 10.0.1.50,10.0.1.51 and 10.0.1.50, 10.0.1.51 are the same. When you leave the field, it shows the parsed list, one entry per node, joined by ", ". Used for inventory collection and, in SSH ingest mode, for SSH log retrieval.
Management Host / IP * (source devices)	The hostname or IP of the ObjectScale management API. Enter the hostname or IP only. The port is configured separately.
Management Endpoint * (vault devices)	The full URL of the ObjectScale management API, including scheme and port, for example https://10.0.2.50:4443.
Username *	The ObjectScale management API username. Masked after save.
Password *	The ObjectScale management API password. For saved devices, leave it blank to keep the current value. For new devices, you must enter a password before saving.
Data Access IP or DNS Name *	The S3-compatible endpoint URL for this device, for example https://192.0.2.61:9021. All Cyber Vault copy jobs use it for object reads and writes. It must include scheme and port.
Ignore management API SSL certificate	Optional. When selected (the default), TLS certificate validation is skipped for management API connections. Most ObjectScale nodes need this because they use self-signed certificates.
Ignore SSL certificate (Data Access)	Optional. When selected (the default), TLS certificate validation is skipped for S3 data connections. In production, clear this checkbox on the device and click Save after you supply valid certificates.
ECS Deployment Type	Controls which remote log directory the ingest service reads from. Shown for source devices only. See below.
Ingest Threads Per Node	A per-device setting. See below.
SSH Sessions Per Host	A global setting for SSH ingest. See below.

The Ingest schedule for source devices is configured globally on System Jobs > Schedules, not per device.

ECS Deployment Type

Option	Log path used
ObjectScale / Virtual ECS (default)	/var/log/vipr/emcvipr-object
Hardware ECS Appliance	/opt/emc/caspian/fabric/agent/services/object/main/log
Custom	A free-text path you supply.

• Select Hardware ECS Appliance for physical Dell hardware nodes.
• The default ObjectScale / Virtual ECS is correct for VM-based ObjectScale deployments.
• Use Custom only if your deployment stores logs at a non-standard path.
• Existing devices without this field saved default to ObjectScale. VM-based sources need no action.

Minimum permissions for the SSH user

The SSH account needs only:

• Login access.
• Read and directory-listing permission on the log path for the selected Deployment Type.

It needs no sudo, no write access, and no shell or command execution. The system only lists and reads files over SFTP.

Grant the account read access to that specific directory instead of assuming it has access by default. File and directory permissions vary by deployment and hardening posture.

Ingest Threads Per Node

This setting controls how many parallel threads drain a backlog of rotated gz log files on each ObjectScale node. Each thread opens its own SSH session to that node.

• Choose 1–8 threads per node. The default is 1 (serial).
• Nodes are also processed in parallel, so the total is about node count × this value, capped at 32 ingest threads overall.
• The active log file on each node is always read by a single thread.
• gz files that were already ingested are skipped.
• Recommended: 4, for fast catch-up without saturating ObjectScale. Separate SSH connections are limited by the SSH server's MaxStartups setting, and MaxSessions (default 10) limits the sessions inside one connection. Keep headroom under both for operator and monitoring access.

info

The first ingest of a node does not pull every rotated dataheadsvc-access.log.*.gz on the array. It reads only the active log file. It records all pre-existing gz archives with the SKIPPED status. They are not downloaded and have 0 records. You can see them on the Ingest Offsets page and in Job details. This avoids a heavy first-run load.

Ingest Threads Per Node therefore matters mainly for catch-up after downtime. Several logs may have rotated while the product was offline. Those newer archives are still ingested and reach COMPLETE. The setting does not matter for the initial history.

SSH Sessions Per Host

This setting appears in a separate SSH Ingest Settings card for the SSH / SCP Log Files ingest method.

Unlike Ingest Threads Per Node, it is global to the SSH ingest method. It applies to every source device that uses SSH ingest.

It caps how many concurrent SSH sessions the system opens against a single ObjectScale node address at once. The cap covers every way a session can be opened for that node:

• The main active-log reader.
• Any extra ingest threads for that node.

The cap exists because the ObjectScale SSH server enforces its own MaxStartups limit on simultaneous connection attempts per address. If the system opens more sessions than the server allows in a short window, the server refuses the burst with connection resets instead of queuing it. This shows up as SSH ingest errors that look like a network problem but are self-inflicted.

Item	Value
Global field	sshSessionsPerHost
Default	4
Reasonable range	1–100

• Lower it if the target SSH server is fragile, rate-limited, or has a conservative MaxStartups.
• Raise it if Ingest Threads Per Node is set high on several devices that share the same node, and the server has a correspondingly generous MaxStartups.

Management Access (mgmtEndpoint)

The Management Access section configures the ObjectScale REST management API connection. It is separate from the S3 and SSH credentials.

Field	Description
Management Endpoint	The full URL of the ObjectScale management API, for example https://192.0.2.61:4443. Include the scheme and port.
Management Port	Defaults to 4443. Override it only if the management API listens on a non-standard port.
Management Username / Password	Credentials for the ObjectScale management REST API. They are used for inventory scanning (listing namespaces, buckets, and replication groups) and for Cyber Vault provisioning. They are separate from SSH and S3 credentials.
Ignore Certificates	When selected (the default), TLS certificate validation is skipped for the management API connection. Required for ObjectScale nodes that use self-signed certificates.
Test Auth	Validates the management credentials with a full login and logout against the configured endpoint.

On success, Test Auth shows the detected ObjectScale software version inline and saves it to the device record. The version appears immediately in the Registered Devices table as a green badge, and stays as a gray badge on later page loads.

• If the version cannot be detected because the device exposes no version endpoint, auth success is still reported.
• If the version changes, for example after an upgrade, click Test Auth again to overwrite the stored version.

Required ObjectScale management roles

The management account needs different ObjectScale privileges depending on whether the device is registered as a Source or a Vault. Each device's management credentials are independent. Use a separate, correctly scoped account for each, not one shared account with too many privileges.

Source devices

The role depends on how many namespaces the system protects on the device.

Namespaces protected	Required role
One	System Monitor, plus Namespace Administrator on that namespace. This is least privilege.
More than one	System Admin.

ObjectScale allows a management user to be Namespace Administrator of only one namespace. System Monitor plus Namespace Administrator therefore cannot cover several namespaces. System Admin has no such limit, but it is not least privilege.

With System Monitor plus Namespace Administrator:

• System Monitor is a cluster-wide grant. It covers the read and discovery operations on a source device: listing namespaces and buckets during inventory scans.
• Namespace Administrator is granted per namespace, not cluster-wide. Add the account to that namespace's Namespace Administrators list on the ObjectScale side (Manage > Namespace > [namespace] > Edit). It covers creating the per-namespace read-only service account and granting it bucket-policy access to the buckets being synced.

info

Full System Admin is not required for a source device that protects a single namespace. If you protect a second namespace later, switch the account to System Admin.

Vault devices

The minimum required role is System Admin.

The system creates a vault device's namespaces and buckets on first use, and ObjectScale permits namespace creation only under the System Admin role. No lesser role supports it. System Monitor and Security Admin are not needed in addition to System Admin.

Vault agent credential ownership

This tab has no credential-ownership controls. When a group enters Vault Mode (in Cyber Vault > Vault Operations), ownership of a vault device's service-account operations moves from the console to the vault agent. This lets the agent operate inside the vault network without a live console connection.

To see whether the console or a vault agent currently owns each vault device, open Cyber Vault > Vault Operations > Target Auth Service Accounts.

Status and actions

Control	Description
Status Badge	Shows the timestamp of the last successful ingest run. A stale or missing timestamp means the ingest schedule has not run or has been failing.
Run Inventory Scan	Queries the ObjectScale management API to list all namespaces and buckets. Requires valid management credentials. See below.
Run Ingest Now	Starts an ingest cycle for this device immediately, outside the normal schedule. Unsaved changes are saved first. Follow progress in System Jobs. Useful after configuration changes or to recover from a missed window.

Run Inventory Scan: node_inventory step

After the buckets are saved, the scan runs a fourth step, node_inventory. It collects the usable capacity of every ObjectScale node for node-tier licensing. The hardware-model read is disabled in 3.0, so every vault node counts as tier A (archive).

Licensing counts the Vault Cluster devices, where the protected copies are stored.

• Vault devices are scanned on the same schedule but run only this step. Their buckets are not added to the inventory.
• Source devices run the step too, but their nodes are stored for reference only and are not counted.
• The step log begins by saying which case applies.

Usable capacity

For each node listed by the ObjectScale management API (/vdc/nodes), the step reads the node's usable capacity (usable_gb, in GiB). It converts it to whole TB, rounding up per node. For example, 3,073 GiB counts as 4 TB. Licensing uses this rounded per-node figure.

Reading it needs a management account with the System Monitor or System Admin role. A namespace-admin-only account gets a WARNING instead of a capacity.

Hardware model

The hardware-model read over SSH and SFTP is disabled in 3.0. The step reads no hardware model and no SSH credentials are needed for it. For licensing, every vault node counts as tier A (archive).

How the step behaves

• Federation audit peers run only this step. Their buckets come from the primary VDC, but each VDC in an ObjectScale federation has its own nodes. The scan logs in to the peer's own management API with the peer device's credentials and stores its nodes under the peer device. For licensing to count the whole federation, register every VDC and give each one management credentials with the System Monitor or System Admin role.

• Vault devices log in to the management API at their Management Endpoint. Every vault node counts as tier A (archive) for licensing.

  A disabled vault device is not scanned, and its nodes are not counted.

• The step never fails the scan. If a node's capacity cannot be read, the step log shows a WARNING with the reason and the node_inventory step is shown as failed. Possible reasons are a refused management API or an unreachable node. The scan job itself still completes and the bucket inventory is saved.

• Results appear as one log line per node and in the job result under nodes. Each node has the node ID and name, IP, drive type, usable GiB and TB, licensing node type, and any capacity error. The last log lines give the device's total usable TB and what was stored.

Vault devices in Vault Mode

In Vault Mode, the vault network is airgapped. The vault agent contacts the console during its open window, but the console cannot reach the vault. The vault agent therefore collects the node facts for these devices, not this scan.

• The scheduled scan and Run All skip a vault device that has at least one protection group in Vault Mode. Settings shows its Vault Lifecycle State as vault mode.
• Run Now on such a device is refused with a message saying so.
• The vault agent that holds the device's credentials reads the same facts from inside the vault. It does this once a day, once after the agent starts, and right after a credential Re-Sync that changes the credentials or SSH settings.
• It reads the node list and each node's usable capacity. It uses the device's Data Node DNS / IPs that ObjectScale confirms as node addresses.
• It sends them to the console encrypted, as a NODE_INVENTORY_REPORT message. The message is listed in Vault Operations > Quantum Trust Protocol Audit Log.
• The console stores the nodes in the same place as the scan does. Licensing counts them the same way.
• If a report cannot be delivered, it is not retried. The next one comes a day later, or after a Re-Sync.
• The agent keeps collecting after Exit Vault Mode as long as it holds the credentials. There is no gap while the console scan takes over again.
• Only the agent that the credentials were delivered to may report a device. A report from any other agent is refused and shows as FAILED in the Quantum Trust Protocol Audit Log.
• A report is also shown as FAILED when the agent could not read the vault at all, for example because the management login failed. The error gives the agent's reason, and the stored nodes are kept.

Changing a vault's SSH settings in Vault Mode does not reach the vault agent by itself. This covers the user, password, port, and Data Node DNS / IPs, and also a management password change.

To deliver the new credentials to the agent:

1. Use the credential button on the vault device in Vault Operations > Vault Device Management.
2. Use Push Credentials or Re-Push to send them, then Re-Sync once they are delivered.

Until then, the agent uses the old credentials.

Each stored node records who wrote it last: console for this scan, or agent: followed by the vault agent's ID for a vault agent report. Agent reports are not console jobs, so they have no scan job ID. The vault agent's log shows each collection.

Licensing node type

Every vault node counts as NODE_TYPE_A (archive) for licensing, because the hardware-model read is disabled in 3.0.

Stored for licensing

After each scan, the nodes that ObjectScale lists are saved, marked as vault or source.

• Licensing counts the nodes of devices that are currently enabled Vault Clusters. Source nodes are for reference only.
• A vault that is disabled or changed to Source stops counting immediately.
• If a node's capacity cannot be read this time, its last good value is kept and the error is recorded with it.
• Nodes that ObjectScale no longer lists are removed.
• If the node list itself cannot be read, nothing is changed.
• Purging the device removes its saved nodes.

Eyeglass device (ransomware detection)

A single card, after the Registered Devices table, configures the console's integration with Eyeglass, Superna's ransomware-detection product.

When it is configured and enabled, it checks every Cyber Vault incremental sync job against Eyeglass's current ransomware-detection status. While the check reports a detection, new and queued incremental syncs are blocked. With the default settings, running jobs finish, because Kill in-flight jobs on detection is off. The check passes until the missed-poll limit is reached. Full-copy jobs are not checked.

The device is a singleton. At most one Eyeglass device is supported system-wide, and it applies to every incremental sync regardless of source. The Add Device button is hidden once a device exists. To replace it with a different one, delete the existing device first.

Field	Description
Name	A display label for this device.
IP / Hostname	The address of the Eyeglass appliance.
API Token	Eyeglass's API key. Encrypted at rest. Leave it blank when editing to keep the existing token.
Monitoring enabled	Turns the whole gating feature on or off. When off, incremental syncs behave exactly as if no device existed.
Poll interval (minutes)	How often the background monitor checks Eyeglass while monitoring is enabled.
Missed polls before treated as detection	How many consecutive failed or unreachable polls are tolerated before an unreachable Eyeglass is treated the same as an active ransomware detection. A single miss below this count is not treated as a detection (it fails open).
Kill in-flight jobs on detection	When off (the default), a detection only raises an alarm and lets already-running incremental jobs continue. When on, every running or auto-paused incremental job system-wide is also canceled. Either way, incremental jobs that are queued but have not started yet are canceled.

How the gate works

This section helps with troubleshooting.

Before a job starts (pre-flight)

Every incremental sync makes one live check against Eyeglass. This covers:

• Scheduled syncs.
• Sync Group Now.
• A bucket's Sync All.
• Sync All Ready.
• A window's Run Sync or Re-sync.
• Either Resume.
• A vault agent's own start-sync.

Full copies are not checked.

The sync is blocked if Eyeglass reports an active event. It is also blocked if the check itself fails and the device's own background monitor has independently confirmed sustained unreachability.

A job row is still created, so the attempt is visible in Copy Jobs history. It is in a terminal Not Started state with Failure reason Ransomware Event. It is never dispatched.

While a job is running (mid-flight)

A background check runs on the configured poll interval. If it detects a problem, alarm CV-115 is raised.

• If Kill in-flight jobs is on, every running or auto-paused incremental job is canceled. Copy Jobs history shows it with status Canceled and Failure reason Ransomware Event.
• Incremental jobs that are queued but have not started yet are always canceled the same way, even with Kill in-flight jobs off, because nothing has been copied yet.

The alarm in the Alarms view represents one detection event, not one alarm per affected job. If several jobs are affected by the same detection, check the Failure column in Copy Jobs history, filtered to Ransomware Event. It shows the full list of jobs that were blocked or canceled. The Alarms view alone may reference only one of them.

Workflows

Add an ObjectScale source device

1. Check that the Ingestion Method card at the top of the section shows SSH / SCP Log Files. The console connects to each ObjectScale node over SSH and copies the audit log files. This is the only ingest method, and it applies to all source devices.
2. Click Add Device and select Source Cluster.
3. Enter the required Device Name.
4. Enter the Node IPs, as comma-separated ObjectScale node IPs or hostnames.
5. Enter Management Host / IP, Username, and Password for the ObjectScale management API (port 4443). See Required ObjectScale management roles. A source account needs System Monitor plus Namespace Administrator when it protects one namespace. It needs System Admin when it protects two or more, because Namespace Administrator covers one namespace only.
6. Enter Data Access IP or DNS Name, the S3 endpoint URL including scheme and port, for example https://10.x.x.x:9021.
7. For SSH ingest, enter SSH User, SSH Password, and SSH Port in the SSH Credentials section. Set ECS Deployment Type to ObjectScale / Virtual ECS, Hardware ECS Appliance, or Custom. ObjectScale 4.x hardware appliances (EX and XF series) need Hardware ECS Appliance. The wrong choice ingests zero records without an error.
8. Click Test Auth to validate the management credentials and detect the device software version.
9. Click Save. The button stays disabled until all required fields are filled.
10. Click Run Ingest Now to verify that the first ingest completes without errors.

Add a Vault device

1. Click Add Device and select Vault Cluster.
2. Enter Device Name, Data Node DNS / IPs, and the full Management Endpoint URL, for example https://10.0.2.50:4443.
3. Enter Username and Password for the management API. See Required ObjectScale management roles. A vault account needs System Admin, because namespace creation on this device requires it.
4. Enter Data Access IP or DNS Name for the S3 endpoint, for example https://10.0.2.50:9021.
5. Optionally select a Replication Group. Click Fetch after saving credentials to discover the groups on the device.
6. Click Test Auth to confirm connectivity. The detected version is saved to the device record.
7. Click Save. The button stays disabled until all required connection fields are filled.

Configure Eyeglass ransomware detection

1. In the Eyeglass Device card, click Add Device. The button is hidden if a device already exists. Delete the existing one first to replace it.
2. Enter Name, IP / Hostname, and the API Token.
3. Select Monitoring enabled. Then set Poll interval and Missed polls before treated as detection to the sensitivity you want.
4. Choose whether Kill in-flight jobs on detection is on (cancel running incremental syncs) or off (alert only, the default).
5. Click Save.
6. To verify that it is active, trigger an incremental sync while a real or simulated detection is active. Then check the Failure filter on Cyber Vault > Copy Jobs - Live View & History for "Ransomware Event". A blocked sync shows status Not Started.

Create a Bucket Group or Sync Schedule Policy

Bucket Groups and Sync Schedule Policies are not on this tab. See the Cyber Vault help page. Both are managed there alongside the protection policies they belong to.

Tips

• ObjectScale audit logs are collected only by SSH ingest. If ingest errors look like network problems, such as connection resets, check SSH Sessions Per Host against the ObjectScale SSH server's MaxStartups limit before you change the network.