One server, permanent standalone

One permanent mode, two system-state storage choices

The single-server quick start and installed single-server service both use permanent standalone. For a planned multi-server deployment, use cluster installation instead. A cluster's first bootstrap node is not a single-server product mode.

Default: authority on data drives. Metadata, WAL, identity, queues, and other system state use the fixed disk-journal quorum. The system/cache root is disposable. With D=0 there is only one journal copy; select independent drives and D>0 for redundancy.

Optional: one dedicated metadata drive. Add --metadata ABSOLUTE_EMPTY_DRIVE_PATH --acknowledge-no-metadata-redundancy during setup. This stores authoritative system state and WAL on exactly one drive. There is no metadata redundancy: losing that drive can make all objects unrecoverable even if their shards and snapshots survive. Data-drive tolerance does not protect this drive. The choice cannot be changed by editing cached configuration.

Permanent standalone uses --deployment-mode standalone, an explicit disk-failure tolerance, and a protected journal membership. It cannot enroll another server or convert to distributed mode. Existing distributed installations must not be converted by editing configuration; use a separately planned export/reset/recreate/import workflow if changing format.

External KMS availability, encryption keys, backups, and object-shard survival remain separate responsibilities in both formats.

Count independent disks, not directories

Choose disk-failure tolerance D before initialization. When enough eligible disks exist, the journal uses N = 2D + 1 members and write quorum W = D + 1. A smaller deployment can use N = W = D + 1; every journal member must then be writable to accept writes. Read quorum is R = N - W + 1. The initialized contract is fixed.

For example, D=1 with three journal disks has W=2 and R=2. D=1 with two journal disks has W=2 and R=1: one surviving copy may permit read-only recovery, but not continued writes. Never lower the quorum to make the node start.

Data-drive replicas must be on independent physical devices. A dedicated metadata drive must also be separate from data devices. Disposable caches need distinct directories, but do not require an extra physical device. Multiple data directories on F: or G: are suitable only for an explicit simulation build; they do not provide independent physical-disk fault tolerance. Simulation and real-device formats cannot be converted into each other.

Server-failure tolerance is always zero. Metadata snapshots use max(D, server tolerance) + 1 replicated storage-disk copies, separately from the journal quorum. See snapshot protection.

Configure and install a single-server service

Download the standard binary for your platform and verify its published checksum. Reserve existing empty data-drive directories. Do not reuse an existing cluster's paths.

x2-node standalone capabilities

On Windows use .\x2-node.exe; on Unix use the installed command or ./x2-node. This command never opens disks. Standard current binaries report activation_enabled: true. An older binary may not support this format: use the matching release guidance, not a distributed-mode workaround.

For example, choose D=1 with three independent empty data drives. Use absolute paths appropriate to your operating system:

./x2-node configure --deployment-mode standalone --disk-failure-tolerance 1 \
  --root '<SYSTEM_CACHE_ROOT>' --admin-user admin --admin-password '<STRONG_ADMIN_PASSWORD>' \
  '<DATA_DRIVE_1>' '<DATA_DRIVE_2>' '<DATA_DRIVE_3>'

In PowerShell use .\x2-node.exe and put the arguments on one line or use backtick line continuations. The command builder provides platform-specific syntax and the optional dedicated-drive acknowledgement. Passwords in commands can remain in shell history; use a protected process environment via X2_ADMIN_PASSWORD instead when practical.

1. Record the physical device inventory and explicit disk-failure tolerance. Create only empty directories on the intended mounted drives.
2. Use x2-node configure with explicit --disk-failure-tolerance D and a --root for disposable caches. It writes ROOT/config/node.yaml. An explicit --config must be an absolute path ending in node.yaml. Omit --metadata unless choosing the acknowledged unreplicated drive. Never pass a join link.
3. Keep credentials out of saved scripts and shell history. Use immediate shard synchronization; standalone rejects deferred or disabled synchronization.
4. Restart with x2-node server --config ABSOLUTE_NODE_YAML. Existing standalone configuration is recovered from the selected authority drive(s), not treated as editable local authority.
5. Install with x2-node service install --config ABSOLUTE_NODE_YAML using administrator/root privileges. Use --start=false only if you want to stage without starting. The service uses the same protected configuration. Check its identity, mounted paths, logs, and restart behavior before storing important data.

Normal installation does not need build tags. Shared-device functional tests require a clearly marked simulation build; they are not physical-disk or power-loss verification.

Keep the protection signals separate

Open Availability & Protection → Disk Durability or use an authenticated system-administrator profile:

xc durability status --profile ops --url https://storage-node.example:8443 --node node-1

Use the selected node's direct endpoint and trusted TLS configuration. --node verifies the responding node; a mismatch fails without fallback. Inspect system authority, WAL location, journal read/write quorums, healthy journal replicas, write availability, snapshot targets, and simulation warnings.

Configured tolerance is not remaining tolerance. Snapshot policy is not a live replica-health scan. Journal readability does not prove that every referenced object shard is readable. Node enrollment, online disk adoption, system-volume lifecycle changes, and node-tolerance edits are unavailable in permanent standalone.

Recover offline without changing the contract

Stop every node instance before x2-node standalone inspect, recover, replace-journal, replace-data, rebind-data, or rebuild-journal. Read the exact binary's subcommand help and preserve the cluster fingerprint, member IDs, source inventory, and confirmation requirements. The site deliberately does not generate destructive recovery commands.

• System/cache-device loss: discover the surviving authority drives and use recover to materialize disposable configuration/cache paths. For dedicated metadata, supply its original drive to --disk. Reinstalling an empty system volume alone does not reinitialize authority.
• Dedicated metadata-drive loss: there is no redundant journal copy to recover or rebuild from. Surviving data shards and snapshot objects are not a complete system backup. Do not initialize an empty replacement as if it were the old authority.
• Normal disk replacement: use the protected replacement workflow, then complete scanner/healing validation. Rebinding a path and replacing a member are distinct operations.
• One surviving journal copy: where supported, rebuild-journal copies that source to every required empty replacement member. This can roll back acknowledged changes and cannot recreate missing object shards. Writes resume only after the original write contract is restored.
• Read-only recovery: explicit foreground server --config ABSOLUTE_NODE_YAML --read-only does not write, heal, or automatically promote. It requires the original read quorum and is not a persistent service setting.

Do not manually delete journal files, snapshot shards, or manifests. Retired snapshot shards are reclaimed through the deletion ledger. Real-drive, power-loss, and installed-deployment qualification remain separate from directory-simulation results.