Exaba Object Storage

Exaba is a software-defined, S3-compatible object storage platform that service providers run on their own hardware. It enables partners to become LocalScalers: local providers of cloud services, delivering storage from facilities they control. Built for managed service providers, cloud providers, and data-centre operators, Exaba runs object storage applications such as ransomware-resilient backup, archive, and long-term retention on commodity x86_64, ARM, or Power servers.

Why Exaba

• Sovereign and white-label. Multi-tenant S3 storage you run on your own hardware, under your own brand. No vendor hosts your data, and there are no proprietary appliances.
• Strong for backup and ransomware resilience. Immutable S3 Object Lock repositories, Certified for Veeam Ready, and compatible with Commvault, Acronis, and rclone.
• Durable, fast, and secure. Designed for greater than 12 nines of durability, 10+ GB/s per node over NVMe-oF and RDMA, with a built-in KMS, FIPS-mode OS, and SOC 2 Type I.

Exaba at a glance

Find your way around

Get started

• Docker / Instant Evaluation (spin up Exaba in minutes)
• Positioning (where Exaba fits)

Understand the product

• Architecture and System Components
• Performance and Durability
• Features (the full capability list)
• Concepts: Clusters, Storage Model, Namespaces, IAM & Auth, Workflow Engine

Deploy and operate

• Hardware Sizing, Production Installation, Upgrades
• Health & Monitoring, Runbooks, Support
• Encryption & Key Management

Use

• Management Overview, GUI / Dashboard, CLI

Integrate

• Veeam Backup & Replication, Rclone, Ecosystem Overview

Secure and comply

• Zero Trust Architecture, SOC 2

Reference

• APIs, Compatibility Matrix, Release Notes, Glossary

Common questions

What can I use Exaba for? Exaba is S3-compatible object storage for applications such as ransomware-resilient backup, archive, and long-term retention. Because it speaks the standard S3 API, any S3-compatible application can use it. See Features.

Is Exaba built for MSPs and service providers? Yes. Exaba enables service providers to become LocalScalers, running white-label, multi-tenant storage and Backup-as-a-Service on hardware they own and control. See Positioning.

Is Exaba ransomware-resilient? Yes. Backups are written to immutable S3 Object Lock repositories, enforced at the storage layer, and this configuration is Certified for Veeam Ready. See Veeam Backup & Replication.

Is Exaba S3-compatible? Yes. Exaba implements the core S3 API (PUT, GET, DELETE, LIST, HEAD, versioning, multipart, and tagging), so standard S3 clients, SDKs, and backup tools work against it. See Features.

Can I run Exaba in production under Docker? Docker is for evaluation only. Production deployments run on Rocky Linux 10 / RHEL 10 across x86_64, ARM, or Power. See Docker / Instant Evaluation.

Does Exaba host my data? No. Exaba is software you run on your own hardware, in your own data center, sovereign by design.

---

Looking for installation, sizing, operations, or KMS guides? In-depth operational documentation is available to Exaba customers. Sign in to Exaba One.

Positioning

Exaba is software-defined object storage that service providers and operators run on their own hardware. Because it is software rather than a proprietary appliance, partners are free to choose how they deploy it: as a highly available cluster, an edge appliance, an OEM-embedded product, or a self-operated air-gapped install.

Who Exaba is for

How Exaba can be deployed

Exaba is the same software in every case; the deployment model is the partner’s choice.

Features

Core Object Storage Capabilities

Operations & Management

Security & Compliance

Performance & Scale

Extensibility & Developer Features

Platforms & Multi-Tenancy

Architecture

This page explains how an Exaba deployment is put together: the node roles, drives, topology, and networking you plan and provide. Exaba installs and configures the cluster on top.

Nodes

An Exaba cluster is built from two node roles:

• Compute nodes (C-nodes). Stateless nodes that serve the S3 client endpoints and handle erasure coding and data placement. Add C-nodes to scale S3 serving and keep compute from bottlenecking; aggregate throughput is typically bounded by network and drive bandwidth.
• Storage nodes (D-nodes). Nodes that hold the drives and present them to the cluster. Add D-nodes to increase capacity.

The two roles can run converged (compute and storage on the same servers, simplest to operate and well suited to backup and capacity workloads) or disaggregated (compute and storage on separate servers, so each scales to the workload).

Drives

Each storage node uses two kinds of drive:

• Metadata drives: fast NVMe drives (a minimum of two per node) that hold object metadata and the data staging area.
• Data drives: hold the object data. Typically HDDs, which give the lowest cost per TB; use NVMe for read-latency-sensitive workloads (hot, small-object, AI/ML reads). With enough HDDs and staging headroom, write throughput is comparable across media.

For minimum and reference hardware specifications, see Hardware Sizing and the Compatibility Matrix.

Highly available vs. Edge

• Highly available (HA) cluster. Starts at three nodes, with five or more recommended, running active/active with no single point of failure; the cluster survives node, drive, and rack failures. It scales out online by adding nodes and drives, with multi-cluster federation for larger footprints. This is the standard production deployment.
• Edge / single node. A single node for a remote or branch site, or for evaluation, without cluster redundancy.

See Positioning for the full set of deployment models, including OEM and air-gapped.

Networking

Plan three separate networks:

• Client network: external S3 API traffic from your applications, typically behind Exaba’s bundled load balancer.
• Data network: a high-bandwidth, low-latency internal fabric carrying storage traffic between nodes over NVMe-oF, on RDMA (RoCEv2 or iWARP) or TCP.
• Management network: out-of-band hardware management (BMC).

What you provide, what Exaba provides

• You provide: commodity x86_64, ARM, or Power servers, their drives, and the network fabric.
• Exaba provides: the software, and installs, configures, and (for connected clusters) monitors the deployment.

System Components

An Exaba deployment is made up of a small set of software components. This page is the component map; for how they are arranged into nodes and clusters, see Architecture.

Data path

The data path has two layers that scale independently: the C-node (compute) and the D-node (storage). See Architecture for how they are arranged into nodes and clusters.

Interfaces

• S3 API: the primary client interface. Standard S3 tools, SDKs, and backup software connect here.
• Admin Portal: the browser-based console for management and observability.
• CLI (exaba-cli): command-line management and automation.
• Management API: REST API for programmatic control and automation of the platform.

Platform services

Exaba One

Exaba One is the remote management and monitoring portal. It provides monitoring and alerting at the deployment level (a deployment is a group of clusters) and the cluster level, plus access to partner materials and billing details.

See also

• Architecture: how these components are arranged into nodes and clusters.
• Features: the full capability list.
• Durability: how erasure coding protects your data.

Performance

Exaba’s performance is an envelope you size to the workload, not a fixed appliance figure. It decomposes into three primitives — throughput, latency, and operation rate — each gated by different hardware. Knowing which one your workload needs is what turns a target into a build. Exaba sizes each deployment with you; this page explains the levers.

Throughput — the baseline

Throughput is the aggregate GB/s the cluster moves, and it is the primitive most deployments size for.

• The data path is NVMe-oF over RDMA, delivering 10+ GB/s of object throughput per node.
• Compute (C) and storage (D) layers scale independently, so aggregate throughput grows linearly as nodes are added.
• Throughput is gated by the network and node count, not the data-drive media. Writes are acknowledged from the NVMe staging area, so HDD data drives sustain full ingest given enough spindles, and HDDs handle large sequential reads (restore windows) well.

To reach the top of the throughput envelope: an RDMA fabric (RoCEv2 or iWARP; TCP is supported for sites without RDMA), high-bandwidth bonded NICs (25–200 GbE), NVMe metadata drives, and enough nodes to hit the aggregate target.

Latency optimisation

Latency is time-to-first-byte per operation, and it splits by direction:

• Write latency is bounded by the NVMe staging area, so with adequate staging headroom it is independent of the data-drive media — HDD and NVMe data drives acknowledge writes equally fast.
• Read latency depends on the data-drive media. This is where NVMe data drives earn their place: latency-sensitive reads — hot tier, transactional, AI/ML — benefit from NVMe, while bulk and sequential reads do not.

Add NVMe data drives when read latency is the constraint; otherwise HDD data with NVMe metadata is the better-value choice.

Operation rate (small objects, high GET/s)

Small-object and metadata-heavy workloads are bound by operations per second rather than raw bandwidth, and the lever depends on the operation. High GET/s of small objects is limited by data-drive random-read IOPS, where NVMe data drives far outperform HDD; this is the primary case for NVMe data. Metadata-heavy operations (LIST, HEAD, indexing) are driven by NVMe metadata drives.

Capacity and cost

For archive and long-term retention, the target is cost per TB, not speed: bulk HDD data with NVMe metadata gives the lowest cost per TB with modest networking. This is the standard backup and retention configuration and trades peak read latency for capacity.

Sizing

Align the hardware to the primitive your workload needs — a throughput figure, a latency or restore-time objective, or a cost per TB. See the Compatibility Matrix for validated fabrics and reference platforms, and Hardware Sizing for the sizing process.

Durability and Availability

Exaba is designed for greater than 12 nines of object durability: in a given year, the probability of losing any one object is less than one in a trillion. That is in line with the durability targets common to hyperscale object storage. This page explains how it is achieved, at the level of the mechanisms involved rather than as a sizing calculation.

How Exaba protects your data

• Erasure coding (MARS). Every object is split into data and parity shards by Exaba’s Multiple Area Reed-Solomon parity engine and spread across drives and nodes, so it survives the loss of multiple drives or nodes and is reconstructed from the surviving shards. How much failure it tolerates is configurable (see Configurable resilience).
• Fault-domain-aware placement. Shards of the same object are placed across independent fault domains (drive, node, rack) so that the failure of any single fault domain cannot exceed the erasure tolerance.
• Online through failure. Within the cluster’s configured resilience, the cluster remains available with no data loss when a drive or node fails — surviving shards reconstruct affected objects on read. The failed drive or node can be evicted to rebuild full parity in the background. See Drive failure.
• Durable before acknowledgement. A write is committed to durable, replicated staging before the client receives an acknowledgement.
• End-to-end checksums. Data is checksummed end to end to detect and repair silent corruption (bit rot).

Configurable resilience

Durability is not fixed. You set resilience targets for a cluster, and the parity engine derives the erasure-coding layout that meets them while making the best use of usable capacity. You choose:

• Node-failure tolerance: how many whole nodes can fail at once without data loss.
• Drive-failure tolerance: how many additional drives can fail beyond that.

Higher resilience means more parity and slightly less usable capacity; lower resilience favours capacity. Exaba computes the optimal shard layout from these targets at cluster creation, and the scheme applies cluster-wide. Per-bucket policy controls versioning, Object Lock, and compression, not the erasure scheme.

Durability and availability are different

• Durability is whether your data is safe. Erasure coding, fault-domain placement, and background rebuilds give Exaba its designed-for greater-than-12-nines durability.
• Availability is whether your data is reachable. Exaba clusters are active/active: every node serves reads and writes and there is no single point of failure, so losing a drive, node, or rack reduces headroom rather than access.

Durability is not immutability

Durability and availability both concern hardware failure. Protecting data against ransomware, malicious deletion, or accidental overwrite is a separate property, immutability, provided by S3 Object Lock. See Features and Veeam Backup & Replication.

Nines are not the whole story

Durability figures expressed in “nines” assume random, independent drive failures. In practice, data loss is usually driven by correlated events: a firmware bug across a batch of drives, an enclosure or power-distribution failure, a rack outage, or human error. Erasure coding alone does not protect against these.

Exaba mitigates correlated failures with fault-domain-aware placement, so that a single enclosure, rack, or power feed cannot take out more shards than the scheme tolerates.

Sizing the scheme

The exact erasure-coding scheme and resilience targets are derived for each cluster from your durability and capacity goals, and set at cluster creation. See Hardware Sizing for the sizing process, or talk to Exaba.

See also

• Performance: how the same data path delivers throughput.
• Compatibility Matrix: validated platforms and reference hardware.

Docker / Instant Evaluation

Exaba ships a Docker image, exaba/exaba on Docker Hub, so you can evaluate the S3 API, the web console, and the IAM flow on a single host in minutes.

Evaluation only. The Docker image is for evaluation and development, not production. It is pre-release software, and the on-disk format may change between versions, which can lose previously written data. For production, see Production Installation.

Quick start

# Pull the image
docker pull exaba/exaba:latest

# Generate an admin password and note it down (the container does not print it)
ADMIN_PASSWORD="$(openssl rand -base64 24)"
echo "Admin password: $ADMIN_PASSWORD"

# Run it: accept the EULA, set the admin user, and auto-provision a cluster
docker run \
  -p 9000:9000 \
  -p 9006:9006 \
  -e EULA=y \
  -e ADMIN_USER=admin \
  -e ADMIN_PASSWORD="$ADMIN_PASSWORD" \
  exaba/exaba:latest

CLUSTER_NAME and CLUSTER_GB auto-provision a ready-to-use cluster on startup, so the S3 endpoint is usable immediately with no manual cluster setup. Sign in to the web console as the admin user with the password printed above.

Once it is running:

• S3 endpoint: http://localhost:9000
• Web console: http://localhost:9006

The container is ephemeral by default; restarts lose data unless you mount a host directory at /data (add -v /data:/data to the run command).

The Docker Hub page is the official, always-current reference for the image, its tags, and run options.

Ports

Docker image environment variables

These variables configure the eval container at startup:

How Exaba configuration works

Beyond the image variables above, Exaba services are configured through environment variables that follow a consistent pattern:

EXABA_<SERVICE>_<SECTION>_<KEY>

• <SERVICE> is the component, for example MAXIO (object storage), KMS, IAM, DNS, or SYNC.
• <SECTION>_<KEY> maps to a setting in that service’s configuration file. For example, EXABA_MAXIO_STORAGE_<KEY> overrides the matching key in the [Storage] section of the MaxIO configuration.
• Names are uppercase, and an environment variable overrides the value set in the config file.
• List values are comma-separated.

Most evaluations need only the image variables above; the EXABA_ variables are for advanced tuning.

See also

• Docker Hub: exaba/exaba: the official image and run reference.
• Compatibility Matrix: what is validated against the same S3 surface the eval image serves.
• Hardware Sizing: for when you graduate from the eval container to real nodes.

Ecosystem Overview

Exaba is S3-compatible by design, so tools that speak the S3 API work against it without a custom plug-in or fork. Point your existing S3 clients, SDKs, and backup software at an Exaba endpoint and they behave as they would against any standard S3 target.

Integration guides

More integration guides are added over time.

Missing an integration guide? Request one here and we will look at adding it.

Will my tool work?

If a tool targets the published S3 API with AWS Signature Version 4, it is expected to work with Exaba. Tools that are not on the list above are not necessarily incompatible; they simply have not been through a dedicated setup guide. For the authoritative list of what Exaba is certified or validated against, including the S3 protocol surface, clients, backup products, operating systems, network fabrics, and identity providers, see the Compatibility Matrix.

Veeam Backup & Replication

Exaba is Certified for Veeam Ready as an object storage repository for Veeam Backup & Replication 12 and 13. The same certification also covers Veeam Backup for Microsoft 365 v8 and the Veeam Agents for Windows, Linux, and Mac.

The same Veeam S3 plug-in that targets any S3-compatible repository targets Exaba: there is no Exaba-specific plug-in and no behavioural quirk to work around. If your Veeam team has ever configured an S3 object storage repository, they have everything they need to point it at Exaba.

Why Veeam Ready matters for ransomware posture

Veeam uses S3 Object Lock (Compliance mode) to make backups immutable while a retention period is in effect. An attacker who compromises the Veeam server cannot delete or alter locked backups during the retention window, because immutability is enforced at the storage layer, not by Veeam’s policy engine.

Exaba implements Object Lock at parity with the published S3 API. The Veeam Ready certification covers exactly this configuration: Veeam writes its backups to an Exaba bucket with Object Lock enabled, and the backups stay immutable for the configured retention regardless of what happens to the Veeam server or the network it sits on. That is what buyers mean by a ransomware-resistant backup target.

What you can do with Exaba and Veeam

Prerequisites

• Veeam Backup & Replication 12 or 13.
• Network reach to the Exaba S3 endpoint over HTTPS (port 443). Veeam requires TLS for object storage; have the endpoint’s certificate trusted by the Veeam server.

The certification was validated against a defined reference configuration. See the Veeam Ready listing for the tested hardware and the full set of certified Veeam products.

Step 1: Create the bucket

1. Create a bucket dedicated to Veeam, with Object Lock enabled at creation time. Object Lock cannot be enabled on an existing bucket (a protocol-level constraint, the same as AWS S3).
2. Ensure versioning is enabled (Object Lock requires it).
3. Do not set a bucket-level default retention. Veeam applies retention per object; a bucket default can cause unpredictable behaviour and data loss.

Step 2: Create an IAM user for Veeam

1. Create an Exaba IAM user for Veeam, then issue an access key and secret and hand them to your Veeam administrator.
2. Grant the user a role scoped to the Veeam bucket only. Exaba uses AWS-style JSON policy documents; the policy below mirrors Veeam’s documented permission set for an immutable S3 object storage repository (Veeam KB3151). Replace veeam-backups with your bucket name:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VeeamBucketAndObjects",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketLocation",
        "s3:GetBucketVersioning",
        "s3:GetBucketObjectLockConfiguration",
        "s3:ListBucketVersions",
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:GetObjectRetention",
        "s3:GetObjectLegalHold",
        "s3:PutObjectRetention",
        "s3:PutObjectLegalHold"
      ],
      "Resource": [
        "arn:aws:s3:::veeam-backups",
        "arn:aws:s3:::veeam-backups/*"
      ]
    },
    {
      "Sid": "VeeamListBuckets",
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets",
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::*"
    }
  ]
}

s3:ListAllMyBuckets is only needed if your Veeam administrator browses for the bucket; from Veeam 11a onward it can be omitted when the bucket name is entered manually. For defence in depth, attach the same scope as a per-bucket policy as well: Exaba evaluates RBAC and the bucket policy together, so both must permit an operation. See the IAM Walkthrough.

Step 3: Add the repository in Veeam

In Veeam, go to Backup Infrastructure → Backup Repositories → Add Repository → Object storage → S3 Compatible, then:

• Name: a name for the repository.
• Service point: the Exaba S3 endpoint as an HTTPS URL, for example https://s3.example.com.
• Region: any non-empty string (i.e. exaba).
• Credentials: the access key and secret from Step 2.
• Bucket: browse and select the Veeam bucket. Leave “create new buckets automatically” unchecked and select an existing folder (or create one) inside the bucket.
• Make recent backups immutable: enable it and set the period in Compliance mode. Veeam caps the period at 90 days in the UI; set it at least as long as your shortest retention and align it with your GFS policy.

Step 4: Attach it

Choose the model that fits your environment:

• Direct-to-object (Veeam 12+): use the Exaba repository directly as the target of a backup job.
• Scale-Out Backup Repository: attach the Exaba repository as the Capacity Tier (or Performance Tier) of an existing SOBR.

On the backup job, Local target (large blocks) storage optimisation is recommended for object-storage uploads.

That is the entire configuration. There are no Exaba-specific flags, no headers to set, and no plug-ins to install.

Step 5: Run and verify a backup

Run a backup job, then complete the procurement-grade verification before declaring the migration done:

1. Confirm immutability is applied. Backup objects in the Exaba bucket carry an Object Lock retention attribute.
2. Attempt to delete a locked object before retention expiry. Confirm the delete is rejected with 403. This is the ransomware-resistance assertion.
3. Attempt to lower the retention on a locked object before its retention has expired (Compliance mode). Confirm it is rejected.
4. Run a restore. Confirm restore latency and throughput match your DR runbook expectations.
5. Run the S3-compatibility harness against both an existing S3-compatible target and the Exaba cluster, and diff the result logs. The Veeam Ready certification covers this configuration; running the harness gives you an audit-grade artefact for your file.

Exaba is one layer in your data-protection strategy

Important: Exaba provides a durable, immutable backup target, but it is one layer in a broader data-protection strategy, not a complete one. Follow established practice: keep multiple copies, in independent locations, and verify them regularly. Customers are responsible for configuring and operating Exaba appropriately for their environment.

Where to go for help

• Veeam-side configuration questions: your Veeam support contact. Exaba is a certified target, so Veeam’s normal support channel covers the integration.
• Exaba-side bucket, IAM, and Object Lock questions: see Production Installation, IAM, and the User Manual PDF shipped with your release.
• Performance tuning for the backup window: see Hardware Sizing. Backup throughput is often the deciding factor in the cluster spec for backup-target deployments.

See also

• Compatibility Matrix: the authoritative list of what Exaba is certified or validated against.
• APIs: S3-compatible object API is the protocol surface that Veeam uses.
• Migration from AWS S3: if you are moving an existing AWS-backed Veeam repository.
• Veeam Ready listing for Exaba: the official certification, tested configuration, and certified Veeam products.

Acronis Cyber Protect

Acronis Cyber Protect backs up to S3-compatible object storage. Because Exaba presents a standard S3 API, Acronis can use an Exaba cluster as a backup storage location, including for immutable backups via S3 Object Lock.

Compatibility note. Acronis Cyber Protect targets Exaba through the standard S3-compatible API. Acronis publishes an official Exaba S3 storage integration, and backups and restores have been tested by Exaba.

Prerequisites

• Acronis Cyber Protect Cloud (or Acronis Cyber Protect), with a backup or management agent installed.
• Cyber Administrator or Company Administrator access in Acronis.
• Network reach to the Exaba S3 endpoint over HTTPS (port 443), with a TLS certificate the Acronis agent trusts.
• A dedicated Exaba IAM user. Acronis does not accept root or admin access keys for a backup location.

Step 1: Create the bucket

1. Create a bucket dedicated to Acronis. For immutable backups, enable Object Lock at creation time (it cannot be enabled on an existing bucket) and ensure versioning is enabled.
2. Do not set a bucket-level default retention. Acronis applies immutability per object based on its own retention setting (Step 4); a bucket default can conflict and cause unpredictable behaviour.

Step 2: Create an IAM user for Acronis

1. Create an Exaba IAM user for Acronis, then issue an access key and secret. Do not use root or admin keys.
2. Scope a role to the Acronis bucket only. The policy below covers the S3 and Object Lock operations Acronis uses for immutable backups, scoped to a single bucket for least privilege. Replace acronis-backups with your bucket name:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AcronisBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketLocation",
        "s3:GetBucketVersioning",
        "s3:GetBucketObjectLockConfiguration",
        "s3:ListBucket",
        "s3:ListBucketVersions"
      ],
      "Resource": "arn:aws:s3:::acronis-backups"
    },
    {
      "Sid": "AcronisObjects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:GetObjectRetention",
        "s3:PutObjectRetention"
      ],
      "Resource": "arn:aws:s3:::acronis-backups/*"
    },
    {
      "Sid": "AcronisListBuckets",
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Resource": "arn:aws:s3:::*"
    }
  ]
}

These are the S3 and Object Lock operations Acronis uses for immutable backups. See the IAM Walkthrough for creating users, roles, and bucket policies on Exaba.

Step 3: Add the storage location in Acronis

In Acronis Cyber Protect Cloud, go to Backup Storage → + Add Location → Public cloud → S3 compatible → Connect, then provide:

• Management agent: the agent that will manage this location.
• Endpoint URL: the Exaba S3 endpoint as an HTTPS URL, for example https://s3.example.com.
• Access key ID / Access key secret: the credentials from Step 2.
• Location name: a name for the location.
• Bucket: select the Acronis bucket.

Step 4: Enable immutability

Acronis immutable storage uses S3 Object Lock. When adding the location, enable Backup immutability period (Days) and set the number of days. The bucket must have Object Lock enabled (Step 1).

Limitation on Exaba today. Acronis’s immutability guidance relies on an S3 lifecycle rule to delete noncurrent object versions and keep storage from growing. Exaba’s lifecycle policies are on the roadmap and not shipping yet, so that automatic cleanup is not available; plan capacity for retained noncurrent versions until lifecycle support ships.

Step 5: Run and verify

1. Apply a protection plan that targets the Exaba location and run a backup.
2. For immutable backups, confirm the resulting objects carry an Object Lock retention attribute, and that an attempt to delete a locked object before retention expiry is rejected with 403.
3. Run a restore to confirm recovery works end to end.

Exaba is one layer in your data-protection strategy

Important: Exaba provides a durable, immutable backup target, but it is one layer in a broader data-protection strategy, not a complete one. Follow established practice: keep multiple copies, in independent locations, and verify them regularly. Customers are responsible for configuring and operating Exaba appropriately for their environment.

See also

• Acronis: Exaba S3 storage integration: the official Acronis integration page for Exaba.
• Compatibility Matrix: what Exaba is validated against.

Rclone

Rclone is a command-line program for syncing and copying files to and from S3-compatible object storage. It’s the right tool for ad-hoc copies, scripted backups, and one-shot data migrations.

Exaba is validated against Rclone: full sync, copy, and mount workflows are part of routine integration testing. Rclone’s s3 backend includes a built-in Exaba provider, so there is no fork or custom build to install. See Rclone’s Exaba documentation for the upstream reference.

Configuration

Add an Exaba remote to your Rclone config (~/.config/rclone/rclone.conf):

[exaba]
type = s3
provider = Exaba
endpoint = https://your-exaba-endpoint.example.com
access_key_id = your-access-key
secret_access_key = your-secret-key
acl = private

The values that matter:

• provider = Exaba selects Rclone’s built-in Exaba provider, which applies the right S3 behaviour for an Exaba endpoint.
• endpoint: your Exaba cluster’s S3 endpoint URL.
• access_key_id / secret_access_key: issued by Exaba IAM. Scope the underlying role to the buckets this remote will touch.
• region: leave blank. Exaba does not require one.

Test the remote:

rclone lsd exaba:                  # list buckets
rclone ls exaba:my-bucket          # list objects

Common workflows

Sync a local directory to Exaba

rclone sync /local/path exaba:my-bucket/prefix \
    --transfers 32 \
    --checksum \
    --progress

• --transfers 32 parallelises the upload; tune to saturate your uplink without overwhelming the source filesystem.
• --checksum makes the sync idempotent: re-running picks up only changed files based on checksum, not modification time.

Copy between two S3-compatible targets

Rclone can copy directly between two S3 remotes without staging through local disk. This is the right pattern for migrations from AWS S3 to Exaba. See Migration from AWS S3: Pattern 1.

rclone copy s3-aws:source-bucket exaba:destination-bucket \
    --transfers 32 \
    --checksum

Mount a bucket as a filesystem

rclone mount exaba:my-bucket /mnt/exaba \
    --vfs-cache-mode full \
    --dir-cache-time 1m \
    --daemon

--vfs-cache-mode full is the right mode for general read/write workloads. For read-only or append-mostly workloads, writes suffices and uses less local disk.

Object Lock with Rclone

Rclone’s s3 backend supports Object Lock retention and Legal Hold through standard S3 headers, which Exaba implements at parity. The Compatibility Matrix: S3 protocol surface lists the validated Object Lock features.

For backup-target workloads driven by Rclone, the recommended pattern is to create the bucket with Object Lock enabled at creation time and rely on bucket-level default retention rather than setting retention per-object.

Performance notes

• Multipart threshold: Rclone’s default chunk size is reasonable for most workloads. For very large objects (>100 GB), increase --s3-chunk-size 64M to reduce metadata overhead.
• Concurrency: --transfers N controls parallel object transfers; --s3-upload-concurrency N controls parallel parts within a single multipart upload. Tune both for your specific source/destination/network.
• Checksums: Rclone validates Exaba’s content-MD5 checksums on download. For end-to-end integrity, do not disable checksums (--no-checksum) or TLS verification (--no-check-certificate).

See also

• APIs: S3-compatible object API
• Compatibility Matrix
• Migration from AWS S3: full migration playbook using Rclone (and other patterns).
• Rclone S3 docs, Exaba provider: https://rclone.org/s3/#exaba.

Zero Trust Architecture

Exaba’s internal architecture is zero-trust by construction: identity is cryptographic, not topological. A request is trusted because it presents a current X.509 leaf certificate signed by the cluster’s intermediate CA, not because it arrived on a particular IP, network segment, or VLAN.

Mutual TLS on every internal hop

Every service-to-service call inside an Exaba cluster is authenticated and encrypted with mutual TLS (mTLS). There is no fallback path that admits an unauthenticated request on the assumption that the underlying network is trusted.

When a request arrives at any internal endpoint, the mTLS layer:

1. completes the mutual TLS handshake,
2. extracts and validates the peer’s certificate,
3. reads the service identity and role grants encoded in the certificate, and
4. rejects the request with 401 Unauthorized if any step fails.

Only after identity is established does the request reach the handler.

Identity is a signed property of the certificate

Role grants for every internal service are signed into the leaf certificate at issuance, so they cannot be forged or upgraded after the fact:

• A caller cannot claim a role it was not issued.
• A compromised network position cannot escalate privilege by impersonating an internal address; the verifier checks the certificate chain, the validity dates, and the signed roles before any handler runs.

Service handlers consult the certificate’s role grants to decide whether the caller is allowed to perform the requested operation.

Pure-mTLS on internal endpoints

Internal service-to-service authentication is mTLS-only; there is no JSON Web Token (JWT) path between internal services. JWTs are used only for end-user-facing interactions with the IAM service, for example browser-driven console login.

For control-plane API calls that need a bearer token, for example audit-trail submissions, services use a Machine-to-Machine (M2M) client that obtains short-lived access and refresh tokens against the control plane over mTLS. Tokens are signed asymmetrically and short-lived, so a stolen token cannot be silently replayed.

Verifier configuration

The internal mTLS verifier requires a valid client certificate on every internal endpoint. “Optional” client authentication is used only at the public client edge, where TLS terminates before traffic enters the internal mesh.

The verifier is keyed off the cluster’s intermediate CA chain, delivered by the control plane at install time. Leaf certificates are short-lived and rotated automatically, so a compromised certificate expires quickly without bespoke revocation tooling.

What this gives you

• No flat-network trust. Internal lateral movement gains nothing without a valid leaf certificate issued by the cluster CA.
• No bearer-token replay across internal services. mTLS-only on internal endpoints removes the JWT replay attack surface that service meshes commonly carry.
• Role separation that survives network compromise. Roles are signed into the certificate, not asserted in headers.
• Short blast-radius windows. Short-lived leaf certificates mean a compromised certificate expires quickly.

See also: System Components for the inter-service map, and Encryption & Key Management for the PKI roots that issue these certificates.

SOC 2

Exaba holds a SOC 2 Type I report from an independent auditor, covering the Security trust services criterion. The report is available to qualifying customers and prospects under NDA on request.

What SOC 2 Type I covers

A Type I report attests that, at a defined point in time, Exaba’s controls are designed appropriately to meet the SOC 2 Security criteria. The report covers Exaba’s product engineering, build, and release processes, not customer deployments.

The control set is supported by a regular penetration-testing cadence operated by an internal red team. Findings flow into the SOC 2 evidence pool, so adversarial assurance evidence is current across the audit window rather than collected only at audit boundaries.

What SOC 2 Type II is

Type II additionally tests that the same controls operated effectively over a sustained period (typically 12 months). Exaba does not currently hold a SOC 2 Type II report. A Type II audit is targeted within approximately three months; talk to your account contact for the current timeline.

Customer responsibilities under SOC 2

A SOC 2 report on the product does not transfer to customer deployments. Operators remain responsible for:

• Their own SOC 2 / ISO 27001 / sector-specific certification scope.
• Cluster configuration, IAM policies, retention settings, and evidence collection appropriate to their compliance regime.
• Verification that their deployment matches the assumptions stated in the SOC 2 report (available under NDA).

Exaba supplies the technical building blocks (mTLS-everywhere via Zero Trust Architecture, structured audit logging, FIPS-aware cryptography, and a hardware-rooted KMS) that make those evidence-collection workflows tractable.

Data protection (GDPR, LGPD)

Exaba is software you run on your own infrastructure, so personal data stays in your environment and jurisdiction; Exaba does not host or process your data. For GDPR, LGPD, and similar regimes, Exaba provides the technical controls that support your compliance (encryption at rest and in transit, IAM and access control, audit logging, and immutability), while data residency and processing decisions remain yours. A formal data-protection posture is available under NDA.

Requesting the report

Contact your Exaba account representative or support@exaba.com. An NDA is required before the report is released.

Compatibility Matrix

Exaba speaks the standard S3 API, and its compatibility is verified continuously: the S3 surface, clients, operating systems, and network fabrics below are exercised on every release against a conformance test harness. Because Exaba is S3-compatible, the broad ecosystem of S3 tools generally works against it out of the box.

This is the authoritative, source-attested matrix. Rows labelled Certified or Validated are backed by the test harness shipped with the cluster, or by the Exaba Security Design report (available under NDA). Anything not listed is simply untested, not incompatible: most tools that target the published S3 API work, and you can confirm yours by running the harness against it (see APIs: S3-compatible object API).

S3 protocol surface

Source: the S3 conformance test harness shipped with the cluster.

S3 clients and SDKs

Clients not on this list (s3cmd, mc/MinIO Client, Cyberduck, s5cmd, Boto3 directly, etc.) are untested by Exaba rather than unsupported; most that target the published S3 API are expected to work, but Exaba has not run them through the harness.

Backup and replication products

Other backup products (Commvault, Rubrik, Cohesity, NetBackup, Bacula, Restic, Duplicati, Velero, etc.) are currently untested by Exaba. Any of them that targets the published S3 API with SigV4 is expected to work, but Exaba has not certified them. If you need a certification for one of these products, contact your account representative or by completing this form.

Operating systems

FIPS-mode runtime uses a FIPS-validated cryptographic provider linked into every Exaba process. Exaba is FIPS-aware (it detects and runs cleanly under a FIPS-mode kernel) but is not itself FIPS-certified.

Architectures

Hardware

Other hardware is deployable (Exaba’s hardware abstraction is deliberately conservative), but only the two profiles above are validated in CI. For a hardware variant you want certified, engage Exaba for a sizing review before placing an order. See Hardware Sizing.

Network fabrics

InfiniBand is not supported. Exaba’s RDMA transport targets RoCEv2 and iWARP over Ethernet, not InfiniBand.

Identity providers

Reading this matrix

• Certified: a third party has issued a certification.
• Validated: Exaba’s CI or harness exercises this on every release.
• Tested: exercised in Exaba’s own testing, without a formal third-party certification.
• Reference architecture: the validated configuration in the Reference Architecture PDF.
• Supported: implemented, with documentation; may not be in every-release CI.
• Untested: Exaba has not tested it. Most S3-compliant tooling works regardless; run the harness against your candidate stack to confirm.
• Unsupported: Exaba does not support this configuration; an install attempt may proceed but is outside the supported envelope.

Glossary of Terms

Exaba Glossary

Access Key / Secret Key

Credentials used for authenticating and authorizing requests made through the S3 API, equivalent to a username/password combination.

Access Control List (ACL)

A set of rules defining permissions for users or system processes to access objects or buckets within the storage system. ACLs specify who can read, write, or manage specific resources.

Accounting

Accounting refers to the tracking and measurement of usage statistics, operational activity, and storage metrics within Exaba’s object storage system. These metrics are used for billing, monitoring, performance analysis, and policy enforcement.

Key measures collected include:

• Total Objects Count:: The number of stored objects (files) in a bucket or across the system.

• Total Storage Used (Bytes):: The cumulative size in bytes of all stored objects, including all object versions and metadata overheads.

• Small Objects Count:: The number of objects that fall below the system-defined minimum object size (e.g., 128 KiB, 4 MiB etc), often used to adjust billing due to metadata and I/O overhead. A common value for hosted SaaS backup storage may be closer to 4 MiB. For example, storing a 1-byte object, and allowing the 1-byte objects to be versioned requires a lot more than the 1-byte of the object size.

• Object Versions Size (Bytes):: The count and total size of object versions, if versioning is enabled.

• PUT Operations:: The total number of PUT operations (uploads), optionally broken down by size class or frequency.

• GET Operations:: The number of GET operations (downloads), used for bandwidth and usage monitoring.

• DELETE Operations:: The count of DELETE requests, including deletes of versioned objects.

• Uploaded Bytes:: The total number of bytes received by the system via PUT, POST, and multipart uploads.

• Downloaded Bytes:: The total number of bytes served in response to GET or HEAD requests.

• Bandwidth Usage (95th Percentile) Mb/s (megabits/sec:: The 95th percentile of ingress and egress bandwidth, typically measured over 5-minute or hourly intervals, used for burst-aware billing.

• Failed or Denied Requests:: Counts of rejected operations, categorized by HTTP status code (e.g., 403, 404, 500), to monitor errors or policy violations.

These metrics may be aggregated per user, per bucket, per tenant, or per access key, and are essential for enforcing quotas, optimizing performance, ensuring fairness, and generating billing reports.

Base-N encoding

Base-N Encoding refers to encoding binary data into textual representations using a set of characters (alphabet). Common variants include:

• Base32: Encodes binary data using 32 characters (A–Z, 2–7), useful for readable encoding.
• Base62: Uses digits (0–9), uppercase letters (A–Z), and lowercase letters (a–z). Often utilized for compact, URL-friendly encodings.
• Base64: Encodes data using 64 characters (A–Z, a–z, 0–9, +, /), widely used in email attachments, URLs, and cryptographic systems.

Billing Unit

A measurement used to calculate storage costs based on factors like data stored, data transferred, and requests made. Understanding billing units helps in managing and optimizing storage expenses. Monthly billing is commonly in units of (decimal) gigabytes (GB) of storage per month. The monthly price is often divided by 720 to get an GB/hour rate.

(b)its vs (B)ytes

MB (Megabyte) and GB (Gigabyte) are decimal-based storage units using powers of 10:

• 1 MB = 1,000,000 bytes
• 1 GB = 1,000,000,000 bytes

MiB (Mebibyte) and GiB (Gibibyte) are binary-based storage units using powers of 2:

• 1 MiB = 1,048,576 bytes (2^20 bytes)
• 1 GiB = 1,073,741,824 bytes (2^30 bytes)

Exaba consistently uses decimal units (GB/TB/PB) for storage measurement and billing clarity.

Block Storage

A storage method breaking data into fixed-size blocks, ideal for databases and high-performance applications requiring fast, low-latency access. It differs from object and file storage by offering direct control over data placement and retrieval, at the cost of reduced flexibility for scaling large data volumes.

Bonding (see LAG and MLAG)

Bonding (also known as link aggregation or NIC teaming) is the practice of combining multiple physical network interfaces into one logical interface, enhancing reliability, redundancy, and network performance.

Bucket

A container within object storage used to store and organize objects (files). Buckets are fundamental storage units accessed through the S3 API.

Bucket Policy

Rules governing access and permissions for buckets, allowing fine-grained control over who can read, write, or manage data.

Cache

Caching temporarily stores frequently accessed or recently used data to significantly improve storage performance and reduce latency. There are several caching strategies optimized for different workloads:

Write-through Cache

In a write-through cache, data written by a client is simultaneously stored both in cache and primary storage. This ensures data integrity, as there is no risk of data loss in the event of cache failure. However, it introduces higher latency during writes, as each write operation waits for acknowledgment from primary storage.

Write-back Cache

A write-back cache temporarily stores data exclusively in cache memory during write operations, deferring writing to primary storage until later. This dramatically improves write performance and reduces latency. To prevent data loss, write-back caches are typically protected by non-volatile RAM (NVRAM), battery, or capacitive backup solutions. Systems can leverage NVMe-based NVRAM solutions to ensure reliability while maximizing performance.

Write-around Cache

A write-around cache bypasses the cache entirely during write operations, writing data directly to primary storage. Data is only cached upon subsequent read operations. This method preserves cache capacity for frequently read data, making it suitable for workloads with infrequently accessed or very large datasets, as it avoids polluting the cache with data unlikely to be reused soon.

Cache Eviction

The process of removing data from the cache to free up space for new data. Eviction policies determine which data to remove, often based on factors like usage frequency or age.

Chart

Visual tools used to display data storage metrics clearly. Charts include gauges or graphs showing important information like read/write speeds, total storage used, and operational performance (IOPS and latency).

Checksum

A checksum is a short, computed value used to verify data integrity. It detects accidental or intentional changes to data during storage or transmission. Common checksum algorithms include CRC32, MD5, SHA-1, SHA-256, and SHA-512.

Cloud-Native Storage

Storage solutions designed specifically for cloud environments, emphasizing scalability, flexibility, and integration with cloud services and orchestration tools.

Console

An intuitive command line interface providing simplified management, monitoring, and configuration of Exaba storage clusters and services. It can be accessed via terminals or via a web browser which is ideal for users who prefer graphical tools.

CORS (Cross-Origin Resource Sharing)

A mechanism enabling controlled access to resources stored in S3 buckets from different domains or origins, typically used in web applications.

CLI (Command Line Interface, see Exaba CLI)

A simple, text-based tool allowing administrators and advanced users to interact directly with Exaba storage, manage clusters, set policies, and handle data through commands.

Cluster

A group of storage servers (nodes) working together to ensure data is always available, secure, and quickly accessible. Clusters allow the system to scale easily as data storage needs grow.

Cross-Region Replication

Automatically replicating objects between clusters or geographical locations, improving disaster recovery and compliance.

Data Drives

Storage devices specifically used to store the actual user data objects. Exaba separates data and metadata drives to optimize performance, scalability, and reliability.

Data Availability

The degree to which data is accessible and usable upon demand by an authorized entity, ensuring minimal downtime and disruption.

Data Durability

The measure of a storage system’s ability to protect data against loss or corruption over time, often achieved through redundancy, error correction, and regular integrity checks.

Delta Compression

A technique that saves storage space and bandwidth by storing only the changes between different versions of a file, rather than storing each version separately.

DNS (Domain Name System)

DNS is a hierarchical system that translates human-readable domain names (e.g., objectstore.vendor.com) into numeric IP addresses used by computers and network devices. DNS simplifies network access by allowing users and applications to connect using memorable domain names instead of numeric IP addresses.

DNS supports multiple IP addresses for a single domain name (known as DNS round-robin). For example, objectstore.vendor.com may resolve to multiple IP addresses: objectstore.vendor.com resolves to 192.0.2.1, 192.0.2.2, 192.0.2.3, 192.0.2.4, 192.0.2.5 (practically, using actual external IP addresses).

Exaba leverages DNS round-robin to enable a fully active/active cluster architecture, where all resolved IP addresses represent cluster nodes capable of handling simultaneous read and write operations. This ensures strong consistency, high availability, load balancing, and optimal use of network resources.

Docker

Docker is a lightweight containerization technology that packages software applications and their dependencies into isolated containers, ensuring consistency and portability across development, testing, and production environments.

Docker behaves differently across operating systems: Linux: Containers run natively, leveraging kernel namespaces and cgroups for isolation and resource control, providing direct hardware passthrough performance. Windows: Docker supports both native Windows containers (using Windows kernel isolation) and Linux containers, typically via virtualization (e.g., WSL2) for compatibility. macOS: Docker operates through a lightweight virtual machine, since macOS does not natively support container isolation, leading to slightly reduced performance compared to Linux.

Docker storage configurations include: Internal (Overlay Filesystem): Default, ephemeral storage managed by Docker, suitable for temporary data within containers. External (Persistent Storage): Data is stored outside the container via mounted volumes or bind mounts, enabling persistence and direct integration with host filesystems or external storage.

Docker Deployment

A Docker Deployment runs Exaba services within Docker containers: lightweight, isolated environments that package applications and dependencies. Storage can be configured as:

• Internal (Ephemeral): Temporary container storage for quick tests or non-persistent data.
• External: Persistent storage mounted externally via host directories, NFS, or other network storage options, with configurable firewall rules and access controls.

Exaba Topologies

Exaba Topologies define standardized deployment patterns for different usage scenarios:

• Docker Deployment: Container-based lightweight setups ideal for quick deployment and testing.
• Standalone Deployment: Single-node installations without redundancy, suitable for smaller or isolated deployments.
• Highly-Available Deployment: Multiple-node clustered installations providing high reliability, redundancy, and scalability for critical workloads.

Encryption

Encryption is the process of transforming data into an unreadable format using cryptographic algorithms, protecting confidentiality and preventing unauthorized access. The widely-used Advanced Encryption Standard (AES) provides strong encryption commonly used in storage systems.

In the context of S3 storage, encryption typically includes three Key Management Service (KMS) modes:

• SSE-S3: Server-side encryption with one encryption key per tenant (or bucket). Simple and transparent to clients.
• SSE-KMS: Server-side encryption managed by KMS, with a unique encryption key generated for each file, providing enhanced security and fine-grained control.
• SSE-C (server-side encryption with customer-provided keys): the client supplies an encryption key with each request; the server encrypts with it and does not store it. Not supported by Exaba (use SSE-S3 or SSE-KMS).

Exaba CLI

The command-line interface (CLI) for interacting directly with Exaba MaxIO object storage, enabling operations like uploading, downloading, listing objects, syncing data, managing buckets, and performing advanced storage tasks.

 _____           _
  ____|_  ____ _| |__   __ _
|  _| \ \/ / _` | '_ \ / _` |
| |___ >  < (_| | |_) | (_| |
|_____/_/\_\__,_|_.__/ \__,_|

Version: exaba-cli/3.1.0R x86_64/64-bit root
Date: 2025-04-04 08:37:04 +13:00

OS Type: Rocky Linux
Memory:  Free 119.5 GiB / Total 192.5 GiB

exaba> help
Commands:
  node      Configure nodes
  storage   Configure storage
  cluster   Configure cluster
  bom       Generate Bill of Materials
  random    Generate random values
  kms       Exaba Key Management System (KMS)
  top       Display process information
  version   Print component versions
  xc        Exaba S3 commands (buckets, objects, syncing)
  host      Perform DNS lookup
  acc       Exaba Account commands (login/billing)
  ip        Print internal IP(s)
  extip     Print external IP
  info      Print system information
  setenv    Set ENV
  env       Print ENVs
  cwd       Print current working directory
  feedback  Send feedback to Exaba
  history   Print command history
  source    Source a file of valid commands
exaba>

Erasure Coding

A method for protecting data by splitting it into multiple parts, adding special parity information, and distributing it across several nodes. Even if parts of the data are lost or corrupted, the original data can still be reconstructed seamlessly.

Erasure Set

A group of drives within an object storage system configured to work together for data protection using erasure coding. Data and parity information are distributed across the erasure set to ensure redundancy and fault tolerance.

ETag

A unique identifier assigned to an object upon upload, commonly used to verify data integrity or detect changes.

Exaba IAM/Account

Exaba’s secure authentication service, managing user logins and security through JWT (JSON Web Tokens). It holds information specific to each user or tenant account.

Exaba Drive

An easy-to-use, web-based application allowing users to drag-and-drop files for backup, storage, and ransomware recovery directly into Exaba’s object storage system.

Exaba KMS (Key Management Service)

A highly secure, distributed service that manages encryption keys, certificates, and secrets for Exaba’s data storage solutions. It ensures data protection and compliance, especially for sensitive environments.

Exaba MaxIO (MaxIO)

Exaba’s core object storage technology built with Rust, designed for speed, scalability, and compatibility with the industry-standard AWS S3 API. MaxIO ensures efficient storage and retrieval of vast amounts of data.

Exaba Monitor

A dedicated service collecting and displaying real-time statistics and performance metrics from various Exaba components, helping users monitor system health and resource usage.

Exaba Topologies

Exaba Topologies define standardized deployment patterns including Docker-based, single instance (Standalone), or clustered setups for High Availability:

• Docker: Lightweight containerized deployment ideal for rapid testing, small-scale usage, or development environments.
• Standalone (Single Instance): Single-node deployments suitable for small to mid-scale installations without redundancy.
• Clustered (Highly-Available): Multiple nodes deployed as a cluster to ensure redundancy, high availability, fault tolerance, and optimal performance at scale.

File Storage

A traditional storage method that organizes data into hierarchical structures (folders/directories). It’s easy to use for everyday documents but less efficient for massive, unstructured data.

File System

A file system is software that manages how data is organized, stored, and retrieved on storage devices. It defines structures for files, directories, permissions, metadata, and how these are stored physically on drives. Exaba supports various modern file systems optimized for performance, reliability, and scalability, including ext4, XFS, ZFS, and Btrfs, depending on deployment needs.

Firewall

A firewall is a security system (either software or hardware) that monitors and controls incoming and outgoing network traffic based on predetermined rules. Firewalls protect infrastructure by allowing legitimate traffic while blocking unauthorized access, thus reducing exposure to security threats and vulnerabilities.

Exaba uses the host firewall to expose only the ports it needs: the S3 protocol port (443, HTTPS), the management console / UX port, and the internal ports used by the cluster for node discovery and storage traffic. All other ports stay closed.

FIPS (Federal Information Processing Standards)

High-security standards required by governments and regulated industries. Exaba ensures compliance with FIPS, providing secure encryption and data handling.

Flutter/Dart

Flutter is a framework developed by Google for building fast, responsive cross-platform apps for web, desktop, and mobile. Dart is the programming language used by Flutter, known for ease-of-use, rapid development, and strong community support.

Hardened Linux

Hardened Linux refers to a Linux OS configured with strict security measures, reducing vulnerabilities through minimized services, enhanced kernel protection, secure defaults, and mandatory access controls.

Hashing

The use of algorithms to generate a unique, fixed-length value (hash) representing data. Hashing is employed for tasks like data integrity verification and efficient data retrieval.

Healing

The process of automatically detecting and repairing corrupted or lost data within the storage system. Healing mechanisms work to restore data integrity without manual intervention.

Highly-Available Deployment

A Highly-Available Deployment is a clustered Exaba topology designed for maximum uptime, redundancy, and scalability, currently supported only on Linux environments. The Exaba solution is modular, allowing the Exaba MaxIO service (object storage endpoints) and the Exaba Drives (storage nodes) to operate in either:

• Converged Mode: MaxIO services and storage drives run on the same physical nodes.
• Independent Mode: MaxIO services run independently from storage nodes, enabling flexible scaling of data-serving endpoints relative to storage capacity.

Immutable Storage

Storage configuration preventing any modifications or deletions of objects for compliance purposes (such as legal hold, governance, or regulatory requirements) .

IO/s (IOPS)

Input/Output Operations per Second (IOPS) is a measure of how many distinct storage operations (reads or writes) Exaba can process in one second. Higher IOPS indicates better performance, particularly for workloads involving frequent small data operations, such as databases or metadata-intensive tasks.

IP Address

An IP Address (Internet Protocol Address) is a numerical identifier assigned to devices on a network, enabling them to communicate and locate each other. Examples include the local host address (127.0.0.1) used for internal loopback testing. IP addresses are often defined with CIDR notation (e.g., 192.168.1.10/24), where the suffix indicates the network portion length.

IP addresses were historically categorized into three main classes:

• Class A: 0.0.0.0 to 127.255.255.255 – Large networks, fewer network addresses but many hosts.
• Class B: 128.0.0.0 to 191.255.255.255 – Medium-sized networks.
• Class C: 192.0.0.0 to 223.255.255.255 – Smaller networks, numerous networks with fewer hosts each.

Today, CIDR notation is predominantly used for flexible IP allocation.

IP networking often includes bonding, combining multiple network interfaces for redundancy, load balancing, or increased bandwidth.

Key Protection

Key Protection in Exaba KMS refers to safeguarding cryptographic keys using robust methods. Exaba supports multiple protections:

• PlaintextHSM: Simple, transparent storage (primarily for development).
• Passphrase Protection: Root keys are encrypted with user-provided secure passphrases.
• YubiKey/TPM 2.0 HSM: Hardware-backed protection via secure YubiKey / TPM 2.0 devices, ensuring root keys are securely generated, stored, and inaccessible outside the hardware.

KMS (see Exaba KMS)

LAG Networking (Link Aggregation)

Combines multiple physical network links into a single logical connection, enhancing bandwidth and redundancy. LAG helps Exaba achieve high availability and improved network performance.

Latency

The response time measured in milliseconds (ms) to receive or write the first byte of data. Lower latency indicates faster system responsiveness, crucial for performance-sensitive applications. The server-side delay between initiating and completing an individual storage operation within Exaba. Specifically, latency includes the time required to write the first byte during a write operation or receive the first byte during a read operation. Lower latency represents quicker responses from storage, enhancing real-time performance and responsiveness. This measure excludes any delays introduced by client-side networks or applications.

Key Rotation

Key Rotation is the security practice of regularly updating or replacing cryptographic keys to limit exposure in case a key is compromised. Exaba KMS supports:

• Manual Rotation: Initiated explicitly by administrators when required.
• Automatic Rotation: Scheduled periodic rotations (e.g., every 14 days) to maintain continuous compliance and security hygiene.

LAG (Link Aggregation Group)

LAG (Link Aggregation Group) combines multiple physical network links into a single logical connection to increase bandwidth and provide redundancy. LAG requires compatible networking equipment, typically using protocols like IEEE 802.3ad (LACP).

Lifecycle Policy

Automated rules to manage the lifespan of stored data. Lifecycle policies define when data should be moved, archived, or permanently deleted, helping optimize storage costs and compliance. Roadmap.

Limits

Exaba has limits that vary based on physical equipment. Specifically:

• the number of nodes in a cluster
• number and size of the metadata drives
• number and size of data drives

Locking/Unlocking a Vault (see Sealing/Unsealing)

Locking is a synonym for Sealing a vault.

Unlock in a synonym for Unsealing a vault.

M.A.R.S. (Multiple Area Reed-Solomon)

Exaba’s erasure coding method, designed for high data durability and bounded recovery time (see Durability). It encodes objects into data and parity shards across drives and nodes, supporting parallel recovery and configurable resilience.

MaxIO (see Exaba Maxio)

Metadata

Descriptive information about an object, such as creation date, size, content type, and custom tags. Metadata aids in organizing, searching, and managing data within the storage system.

Metadata Drives

Dedicated storage devices specifically optimized to hold metadata: information about the stored data objects (e.g., location, permissions, and attributes). Having separate metadata drives ensures rapid access and management of storage objects.

MLAG (Multi-Chassis Link Aggregation Group)

An advanced form of LAG that aggregates network links across multiple network switches. MLAG provides increased redundancy, fault tolerance, and seamless failover within Exaba’s data center infrastructure.

Multi-Tenancy

An architecture where a single instance of the software serves multiple customers (tenants), ensuring data isolation and customized configurations for each tenant.

Multipart Upload

An S3 API feature allowing large files to be uploaded in multiple parts independently, improving reliability and upload speed.

Namespace

A logical container that groups objects like files and metadata. Namespaces help separate data between different users, teams, or applications, ensuring privacy and security.

Networking

Networking in object storage deployments refers to how storage nodes communicate, manage, and serve data. Typically, Exaba deployments utilize three dedicated networks:

Management Network (BMC): Used for out-of-band management, hardware monitoring, and remote administration through Baseboard Management Controllers (BMC). Usually isolated and secured for maintenance and diagnostics tasks.

Upstream Network (Internet-Facing): Handles client requests, external API traffic, authentication, and access from outside the storage environment. Often includes load balancers and firewalls to manage security and traffic flow.

Data Network: High-performance internal network optimized for storage traffic, including data replication, erasure coding, and synchronization between nodes. Usually utilizes low-latency, high-bandwidth protocols such as RoCE v2 or high-speed Ethernet to ensure maximum throughput and minimal latency.

NFS (Network File System)

Network File System (NFS) is a standardized protocol enabling file sharing over networks, primarily used in Unix/Linux environments. It allows multiple clients to mount and access shared storage remotely, behaving like local storage. Exaba utilizes NFS to provide easy, secure, and scalable file-sharing across multiple hosts, ideal for clustered deployments and collaborative workflows.

Node

An individual server within a cluster that stores data or handles requests. Each node is a building block of a larger, highly available storage system.

Node Rebalancing

The process of evenly distributing data across nodes whenever nodes are added or removed from a cluster, maintaining optimal performance and efficient storage usage.

NTP (Network Time Protocol)

Network Time Protocol (NTP) is a standardized networking protocol used to synchronize system clocks accurately across multiple devices within Exaba infrastructure. NTP ensures consistent timekeeping, essential for accurate logs, security auditing, and coordination between distributed nodes and clusters.

NVMe (Non-Volatile Memory Express)

A modern storage protocol optimized for solid-state drives (SSDs), enabling very high speeds, low latency, and efficient parallel processing of data, essential for Exaba’s high-performance storage solutions.

Object Lifecycle

Policies that define the stages an object goes through from creation to deletion. Lifecycle rules can automate transitions between storage classes or schedule deletions after a certain period. Roadmap.

Object Lock

A compliance feature ensuring stored objects cannot be deleted or altered for a defined period, providing protection against ransomware and accidental deletion.

Object Storage (also see S3)

A storage method designed for scalability and handling large amounts of unstructured data (e.g., images, videos, backups). Object storage stores data as “objects” with unique IDs, accessible via APIs. Key attributes include compatibility with AWS S3, object locking (preventing deletion), immutability (unchangeable data), governance and compliance controls, metadata handling, and flexible access.

Object Tagging

Assigning metadata tags (key-value pairs) to objects for easier management, categorization, lifecycle policy application, and billing insights.

OpenStack

An open-source cloud computing platform that includes components for managing object storage, compute resources, and networking. OpenStack Swift is the object storage component.

Physical ports (Copper vs Fibre)

Exaba networking equipment supports two primary port types:

• Copper Ports (RJ45):

  • Typically used for shorter distances within data centers.
  • Support speeds of up to 1 Gb/s, 2.5 Gb/s, 5 Gb/s, and 10 Gb/s (10GBASE-T).
  • Maximum practical cable lengths: up to 100 meters for 1G and approximately 30–55 meters for 10G.

• Fibre Ports (Optical):

  • Use fiber optic cables to transmit data via light signals.
  • Support significantly higher speeds (10G, 25G, 40G, 100G, 200G, 400G) and longer distances (from hundreds of meters to several kilometers).
  • Preferred for high-bandwidth, low-latency, long-distance networking in Exaba’s storage infrastructure.

Ping

Ping is a diagnostic tool that tests network connectivity and measures latency between hosts. It sends small packets (“echo requests”) to a target server and waits for responses (“echo replies”). Ping is used at Exaba to verify connectivity, troubleshoot latency issues, and monitor network health and performance.

PDU (Power Distribution Unit)

A Power Distribution Unit (PDU) is a device mounted in data center racks that distributes electrical power to servers, storage devices, and networking hardware. PDUs often include features like remote power monitoring, remote outlet switching (for rebooting devices), surge protection, and redundancy. Exaba uses managed PDUs to enhance reliability and allow remote power cycling for efficient hardware management.

Percentile billing (95th)

Percentile billing, commonly known as 95th percentile billing, is a pricing method to fairly charge customers based on their sustained network usage rather than short bursts of high traffic.

• The process
  • Network traffic is continually recorded in both directions (incoming and outgoing) at consistent intervals, typically every 5 minutes, over the entire billing period (usually monthly).
  • Data Buckets: Each 5-minute interval generates a bucket that records the average throughput (e.g., MB/s or GB/s) during that specific interval.
• 95th Percentile Calculation:
  • At the end of the billing period, Exaba sorts all collected buckets from highest to lowest usage.
  • The top 5% of these buckets (representing the highest peaks of traffic) are discarded.
  • The remaining 95% of buckets reflect the customer’s consistent and sustained traffic usage.
  • The billing rate is set at the highest usage value within this remaining 95% (the 95th percentile mark).
• Advantages
  • Fair Pricing: Customers are not penalized heavily for occasional spikes or bursts in traffic, as short-lived peaks are removed from billing calculations.
  • Predictability: Encourages customers to maintain steady and predictable network usage, reducing surprise costs from transient peaks.
  • Cost Efficiency: Customers benefit financially by optimizing their usage patterns to minimize sustained high traffic periods.
• Example
  • For example, consider a month with approximately 30 days × 24 hours × 12 intervals per hour = 8,640 buckets. Exaba discards the top 5% (432 buckets) with the highest usage spikes. The customer is billed based on the highest bucket remaining in the lower 95% (8,208 buckets). This approach helps ensure that charges reflect real, sustained usage rather than brief anomalies or infrequent high-demand events.

Pod

A dedicated, isolated cluster allocated to a specific customer or tenant. Pods ensure data privacy, independent resource management, and tailored performance.

Ports

Ports are numeric identifiers used by network protocols to distinguish between services running on a device, enabling multiple applications to share network resources simultaneously.

Common ports used by Exaba and other network services include:

• Port 80 (HTTP): Standard legacy port for unencrypted web traffic.
• Port 443 (HTTPS): Default secure port for encrypted HTTP (web) communications.
• Port 9000 (S3 API): Standard port commonly used by Exaba, MinIO, and other S3-compatible object storage services.
• Port 9006 (Exaba UX): Default port used by Exaba’s User Experience (UX) management interface and dashboards.

Presigned URL

A secure, temporary URL granting time-limited access to a specific object, typically used for sharing private files or uploading without direct credentials.

PUT / GET / DELETE / HEAD

Core HTTP operations within the S3 API, defining standard actions for uploading, retrieving, deleting, and querying objects.

QR Codes

QR Codes (Quick Response Codes) are two-dimensional barcodes designed to store data in a compact, machine-readable format. They encode URLs, credentials, configuration details, or other information, accessible by scanning with smartphones or scanners. Exaba uses QR codes for secure configuration sharing, quick login authentication, device pairing, and simplified data transfer processes.

Quota

A limit set on the amount of storage space or number of objects a user or group can utilize within the storage system. Quotas help manage resources and prevent overuse.

Rack

A rack is a standardized metal frame used in data centers to securely mount, organize, and manage servers, storage arrays, networking equipment, and other hardware. The width is typically 19 inches. Height is expressed in rack units (U), where 1U equals 1.75 inches. Depth varies significantly and should always be checked when discussing rack options.

RoCE (RDMA over Converged Ethernet)

An implementation of RDMA technology that operates over standard Ethernet networks, allowing the benefits of RDMA (such as ultra-low latency and high throughput) without requiring specialized hardware. Exaba utilizes RoCE to deliver high performance, scalable, and cost-effective storage networking.

RDMA (Remote Direct Memory Access)

A high-performance networking technology enabling direct memory access between servers over a network, bypassing the CPU and operating system layers. RDMA significantly reduces latency, increases throughput, and lowers CPU utilization, making it essential for Exaba’s high-speed storage solutions.

Realm

A high-level organizational boundary (like a customer account) within Exaba, containing multiple namespaces, clusters, and storage settings.

Rebalancing

The automated process of redistributing stored data evenly across nodes or clusters whenever new nodes or storage capacity are added or removed, ensuring optimal performance, storage efficiency, and availability.

RedHat Linux (RHEL)

RedHat Linux (RHEL) is a widely-used enterprise-grade Linux operating system known for stability, security, and support, commonly used in data centres and large-scale deployments.

Ring

A group of multiple clusters within the same namespace, enabling data redundancy, geographic distribution, and consistent management. Rings ensure that even if one location faces issues, data remains accessible from other locations.

Rocky Linux

Rocky Linux is a community-driven, free, and fully compatible alternative to RedHat Linux, created as a direct replacement for CentOS after its discontinuation by RedHat.

Root Keys

Root Keys (or Master Keys) are high-value cryptographic keys used by the Exaba KMS to protect encryption keys for stored data. Root keys are critical to the security of the entire system and require special protection.

Rolling Node Test

Exaba’s capability to seamlessly add, remove, or rebalance nodes and drives within a cluster without interrupting normal operation, ensuring continuous data availability.

Rotation (Key Rotation)

The security practice of regularly changing encryption keys to minimize risks. Exaba automates key rotation, keeping sensitive data protected over time.

Rust

Rust is a modern, memory-safe programming language designed for performance, concurrency, and safety. Widely used in security-critical and enterprise-grade projects, Rust offers:

• Memory Safety: Prevents buffer overflows, memory leaks, and data races.
• High Security: Supports auditable, signed binaries and secure coding practices.
• Performance: Offers speed comparable to C/C++ without sacrificing safety.
• Department of Defense Interest: Recognized by government agencies (e.g., U.S. Department of Defense, NSA) for future projects due to enhanced security and reduced vulnerabilities.
• Concurrent Programming: Safe and efficient multi-threaded execution.
• Community Audited Crates: Security-vetted libraries available through cargo, Rust’s package manager.

S3 (a.k.a. Object Store)

S3 stands for “Simple Storage Service.” Originally created by Amazon Web Services (AWS), it provides an HTTP-based interface to store and retrieve data (objects) at any scale. Exaba’s S3-compatible interface (part of Exaba MaxIO) implements a subset of Amazon S3 APIs, enabling applications and tools designed for AWS S3 to easily migrate to or integrate with Exaba. This includes common operations such as uploading (PUT), downloading (GET), listing objects (LIST), managing multipart uploads, encryption, tagging, and versioning. Exaba’s S3 implementation ensures compatibility with popular backup software and storage workflows.

Samba (SMB/CIFS)

Samba is an open-source software implementation of the Server Message Block/Common Internet File System (SMB/CIFS) protocol. SMB/CIFS is primarily used in Windows environments, enabling clients to share files, printers, and resources seamlessly over the network. Exaba leverages Samba to ensure compatibility and interoperability with Windows-based clients, facilitating easy integration into mixed OS infrastructures.

Scalability

The capability of a storage system to expand its capacity and performance efficiently in response to increasing data volumes or user demands.

SDK (Software Development Kit)

A set of tools, libraries, and documentation provided to developers for easier integration and interaction with Exaba’s storage through code. Exaba’s Rust-based Software Development Kit (SDK) for interacting with Exaba’s object storage platform. The SDK supports parallel operations across multiple IP addresses, threading, pipelining, and load balancing, useful for throughput-bound and latency-bound workloads.

Sealing/Unsealing a Vault

Sealing refers to securely locking the Vault, encrypting its contents, and preventing unauthorized access. Unsealing is the controlled unlocking of a Vault, typically requiring passphrases, hardware tokens, or multiple authorized keyholders, ensuring secure operational management.

SELinux

SELinux (Security-Enhanced Linux) is a Linux security module originally developed by the NSA that enforces mandatory access controls, restricting applications and users to only necessary operations, significantly enhancing system security.

Shortening (URL Shortener)

URL shortening transforms long URLs into shorter, compact versions that redirect to the original web address. Short URLs are easier to share, type, and embed in messages, social media posts, and QR codes. Exaba uses URL shortening to simplify user interactions, improve readability, and facilitate tracking of shared links.

Software-Defined Storage (SDS)

An approach to data storage in which the storage software is decoupled from the hardware, allowing for more flexibility, scalability, and cost-effective management.

Speed / Throughput

The total amount of data transferred to or from Exaba storage over a period of time, typically measured in megabytes per second (MB/s) or gigabytes per second (GB/s). High throughput indicates efficient data movement, critical for backups, restores, and large-scale data processing.

Spine/Leaf Networking

A network architecture featuring a scalable two-layer design. “Leaf” switches connect directly to servers, while “spine” switches connect multiple leaf switches. Exaba uses spine/leaf designs for enhanced scalability, predictable latency, and simplified network management.

SPDK (Storage Performance Development Kit)

An open-source toolkit designed to significantly accelerate storage performance, particularly for NVMe storage devices. Exaba uses SPDK to optimize speed and reduce latency for storage-intensive operations.

SSH

SSH (Secure Shell) is a secure network protocol used for encrypted remote access, command execution, and file transfer between computers. SSH provides strong authentication and confidentiality, making it essential for secure system administration and management.

Staging Area

A replicated area on the NVMe metadata drives where incoming writes are landed durably and acknowledged to the client before being written to the data drives.

Standalone Deployment

A Standalone Deployment consists of a single Exaba node running all services on dedicated hardware or a virtual machine. It’s suitable for smaller workloads or non-critical environments that do not require redundancy or failover.

Storage Classes

Categories of storage designed for specific data access patterns and cost profiles, such as standard, infrequent access, archive, or deep archive.

Stripe Width

Exaba uses variable-width erasure-coded stripes: the number of data shards adapts to the cluster while parity is maintained, so the cluster can shrink or grow without re-encoding existing data. See Durability.

---

Striping

A method of distributing data across multiple storage drives or nodes to enhance performance and storage efficiency. Exaba employs striping to ensure fast and simultaneous data access, significantly improving read/write speeds.

supervisord

supervisord is a lightweight, cross-platform process control system used to monitor and manage long-running processes and services. It offers automatic restarts, detailed logging, and simplified configuration through an easy-to-use interface.

At Exaba, supervisord is optionally used in containerized or development environments to manage and monitor multiple storage processes, APIs, and utilities. Its straightforward configuration makes it ideal for simplified deployments or smaller-scale environments that require efficient supervision without system-wide management overhead.

systemd

systemd is a widely used Linux system and service manager responsible for managing system initialization, processes, daemons, and services. It provides dependency management, automated service recovery, detailed logging (via journald), and efficient startup sequencing.

Exaba uses systemd to reliably control the startup, monitoring, and recovery of its core storage services, APIs, and management interfaces. Systemd service files (.service) define how Exaba’s applications start, stop, and restart, ensuring robust uptime and easy administration.

Tenant

A customer or user account within Exaba’s storage environment. Each tenant has its own isolated resources, storage, and security policies.

TLS (Transport Layer Security)

A security protocol used to encrypt internet communications, commonly recognized by the https:// prefix in web addresses. TLS ensures data transmitted between users and Exaba services remains private and secure.

TLS Certificates

Digital certificates issued to authenticate Exaba services over TLS. These certificates confirm the identity of a website or service, enable secure HTTPS connections, and require periodic renewal, often managed through automated tools like Certbot.

Topology

Topology refers to the physical or logical layout of nodes, services, and networks within an Exaba deployment. A topology defines aspects such as:

• Number of Nodes: The count and arrangement of servers in the deployment.
• KMS Location: Whether the Key Management Service (KMS) is integrated, centralized, or distributed.
• IAM/Auth/Account Services: Placement and redundancy configuration for authentication and account management components.
• Network Configuration: Connections, load balancing, VLAN or subnet designs, and network redundancy considerations.
• Node Specification: Size and capability of nodes in terms of metadata drives (e.g., NVMe SSD) and data drives (e.g., HDD or SAS SSD), including total number of drive bays per node.

TOTP (Time-Based One-Time Password)

A security method generating temporary, unique codes used during login. It provides enhanced security for user and administrator accounts.

Transceivers

Transceivers are modular, hot-swappable components used to convert electrical signals into optical signals (and vice versa). Common form factors and standards used at Exaba include:

Unified File and Object Storage

A storage system that supports both file-based and object-based access methods, allowing users to store and retrieve data using either paradigm within the same infrastructure.

Vault

A Vault is a secure storage component within Exaba’s Key Management Service (KMS) designed for protecting sensitive cryptographic keys, credentials, and secrets. Vaults enforce strict access controls, audit trails, and support secure sealing and unsealing mechanisms.

Versioning

A feature that allows multiple versions of an object to be stored, helping users recover from accidental deletion or overwrites.

VLAN (Virtual Local Area Network)

A virtual network segment that logically groups devices across different physical locations or switches, allowing secure isolation of network traffic within Exaba’s infrastructure for better performance, security, and simplified network management.