AtomOS Docs

Appearance

Storage, vaults, and volumes ​

AtomOS storage is organized in layers: disks and exports on the host, vaults under /mnt, volumes presented to VMs, and attachments tracked by compute services. This page explains terminology, supported backends, lifecycle (including elemento-bin retention), and operational boundaries — without assuming unverified snapshot, HA, or encryption features.

Confirm capability status on your build: Feature availability.

Terminology ​

TermDefinition
Disk / partitionBlock device or partition formatted and mounted for use
Filesystemext4, XFS, ZFS dataset, etc. — how bits are stored on a block device
MountKernel attachment of a filesystem to a path (e.g. /mnt/production)
VaultElemento-managed POSIX directory tree under /mnt/VAULTNAME, configured via atomos-cli
VolumeVirtual disk file or object backed by vault capacity; identified in Electros and on disk
ExportPresentation of storage to consumers (e.g. iSCSI/NFS-style paths where configured)
VM attachmentBinding of a volume to a guest; compute enforces scheduling and migration constraints
Visibility across hostsA volume is usable from another compute node only if your backend and network make the same bits reachable — not automatic for purely local vaults

settings.json

Each vault has a settings.json managed by storage services. Create and edit vaults with --vault-creator and --vault-editor. Hand-editing breaks supported upgrade and validation paths unless Elemento support directs break-glass edits.

Vaults under /mnt ​

Create a vault interactively:

bash
sudo atomos-cli --vault-creator

The wizard collects vault name, maximum volume count, maximum single-volume size, total virtual capacity, and bench tier. Leave the Ceph option set to false unless Elemento instructs otherwise for your deployment. A vault named production maps to /mnt/production; if a compatible mount already exists, AtomOS may reuse it.

Maintain parameters:

bash
sudo atomos-cli --vault-editor
sudo atomos-cli --restart storage

Inspect placement and capacity:

bash
sudo atomos-cli --volume-info

Restart storage only after vault changes and in an approved window — disruptive to I/O.

Storage backends ​

Backends sit under the vault mount. They provide durability and performance; AtomOS vault services provide volume lifecycle and integration with compute.

BackendTypical useAtomOS integration note
Local disk / partitionSingle-node or dedicated storage serversStable vault path when documented in install guides
mdadm (Linux RAID)On-host redundancyTechnically usable on Linux; validate rebuild/monitoring in your lab
ZFSChecksumming, poolsTechnically usable; confirm pool import and mount paths with --vault-creator
GlusterFSDistributed POSIXTechnically usable; not every topology officially tested — verify with support
QuobyteScale-out fileTechnically usable; confirm vendor + Elemento guidance
iSCSISAN LUNsTechnically usable as underlying block; export/listen behavior host-specific
NFSShared filesTechnically usable for mount paths; latency and locking affect VM workloads
Object storageExternal object tiersIntegration depends on deployment — confirm before production

Backends ≠ product HA

RAID, ZFS, Gluster, or replicated SAN protect data on their terms. They do not by themselves guarantee automatic VM failover or zero-downtime compute — see Availability & recovery.

Officially tested matrix rows change by OS and release. Treat Feature availability as the documentation snapshot; prove your backend in a staging cluster before fleet rollout.

Capacity, metadata, and placement ​

  • Virtual capacity and per-volume limits are vault parameters — oversubscription is a policy choice with operational risk.
  • With multiple vaults, storage services place new volumes according to configured constraints and free space.
  • If a vault does not appear in Electros or CLI, check mounts, settings.json (via --vault-editor), and storage service health (--status, --journal storage).

Do not disable or remove a vault that still holds in-use volumes.

Lifecycle and deletion ​

mermaid
flowchart LR
  A[Create vault<br/>--vault-creator] --> B[Create volume<br/>Electros / GUI]
  B --> C[Attach to VM]
  C --> D[Running guest I/O]
  D --> E[Detach / delete in Electros]
  E --> F{Retention policy}
  F -->|elemento-bin| G[Recoverable copy]
  F -->|Purge procedure| H[Space reclaimed]
  G --> I[Manual restore workflow]

When volumes are removed from Electros, data is often retained under the vault’s elemento-bin tree so operators can recover from mistaken deletes. Define retention, monitoring, and purge procedures before production — unbounded retention fills vaults.

Backup

File-level backup of vault trees (e.g. Veeam agent on paths under /mnt) is documented in Backup & recovery. Hypervisor-aware or application-consistent backup without file-level agents is unknown — requires verification on your release (Feature availability).

Exports and network storage ​

Exports (iSCSI targets, network paths on documented TCP ports such as 3260 / storage service ports) must align with firewall, multipath, and Electros network design. See Install & CLI reference.

Storage client REST (TCP 27777) is commonly used on loopback for diagnostics; remote authentication and transport for that API are not verified in public docs — do not expose without Elemento guidance.

Recovery scenarios ​

ScenarioDirection
Accidental volume deleteLocate retained objects under elemento-bin; follow internal restore runbook; contact support if metadata is inconsistent
Vault fullExpand backend or add vault; purge elemento-bin per policy
Storage service crash--status, --journal storage, backend mount health; --restart storage in a window
Host lossRestore from backup; recreate vaults with --vault-creator; restore data paths — RPO/RTO are your design outcomes

No unverified promises

Public docs do not guarantee continuous replication, automatic cross-site failover, or at-rest encryption for every backend. Design those properties explicitly with backend vendors and Elemento support where needed.