Cluster Backup & Restore

DistributedCloudBackupDisaster Recovery

Beta Works · surface still evolving · single-node backup/restore is stable; cluster-wide and continuous modes are evolving — see Maturity below

What it is

Cluster Backup replaces the traditional “lock writes → dump → compress → upload” ceremony with three lighter pieces:

• An anchor is a tiny manifest that pins the cluster’s exact state at a moment and references its data blocks by content hash.
• A background uploader ensures every data block referenced by the anchor exists in object storage, sending only what’s new since the last anchor.
• A restore boots a fresh cluster from an anchor file and is immediately query-ready, pulling data from object storage lazily as queries arrive.

The result is operationally calm: snapshots have near-zero impact on writes, restores produce a working cluster in seconds with nothing pre-loaded, and cloning production into staging copies no data until staging writes something.

Why it matters

Multi-terabyte clusters can’t afford “dump everything” backups, and they can’t afford restores measured in hours. This design leans on immutable data blocks and content hashes to make backup a structural property rather than a separate subsystem.

• Fast snapshot — a single atomic read captures the cluster’s state.
• Incremental by nature — only blocks new since the previous anchor are uploaded.
• Seconds-to-restore — the cluster boots query-ready; data hydrates lazily as queries hit it.
• Zero-byte clone — staging from the same anchor adds no storage cost until staging writes.

flowchart LR
  classDef a fill:#1f2640,stroke:#7c5cff,color:#e8eaf0
  classDef b fill:#1f2640,stroke:#00d4ff,color:#e8eaf0
  classDef g fill:#1f2640,stroke:#4ade80,color:#e8eaf0

  C[Live cluster]:::a --> A[Capture anchor]:::b
  A --> M[Anchor manifest<br/>references blocks by hash]:::b
  M --> G[Background uploader<br/>uploads only new blocks]:::g
  G --> S[(Object storage<br/>S3 / GCS / Azure)]:::g

How you use it

Capture a backup manually, enable continuous backup, or restore a new cluster from any past anchor file.

-- Take a one-shot backup with a friendly tag.
BACKUP CLUSTER TO 's3://aetherius-backups/prod/'
  WITH ANCHOR TAG 'pre-migration-2026';

-- Inspect your backup history.
SELECT tag, timestamp_ns, root_hash, node_count
FROM   _sys_chrono_anchors
ORDER BY timestamp_ns DESC;

-- Configure continuous backup — RPO ≈ anchor interval.
ALTER SYSTEM SET backup_mode            = 'CONTINUOUS';
ALTER SYSTEM SET backup_anchor_interval = '60 seconds';
ALTER SYSTEM SET backup_target          = 's3://aetherius-backups/prod/';
ALTER SYSTEM SET backup_retention       = '30 days';

# Restore — boots query-ready in seconds, hydrates lazily.
aetherius restore --anchor s3://aetherius-backups/prod/anchor-pre-migration-2026.json

The restored cluster announces itself ready as soon as the schema is reconstructed. The first queries trigger background pulls of the relevant data blocks from object storage; over time the hot working set lives locally again.

Maturity

This feature is built from several pieces that don’t all mature at the same pace. A capability is labelled Stable only when it has shipped, has an operations runbook, and has been exercised against multi-terabyte datasets. Beta means functional but lacking one of those. Roadmap means designed and accepted, awaiting delivery.

Capability	Maturity
Anchor capture & single-node restore	Stable
BACKUP CLUSTER DDL, lazy hydration, zero-byte clone	Stable
Multi-node coordinated anchors	Beta
Continuous backup mode	Beta
Cross-region replication	Roadmap
Continuous backup at very large scale	Roadmap
Branch-level anchors	Roadmap

Adopt Stable capabilities without reservation. Treat Beta capabilities as production-eligible with active monitoring and a tested fallback. Plan for Roadmap items but don’t make critical commitments on them yet.

Key concepts

Term	Meaning
Anchor	A small file that pins the cluster’s complete state at a moment and references its blocks by hash.
Background uploader	Pushes new data blocks to object storage; skips blocks already there.
Lazy hydration	Data is pulled from storage to local disk the first time a query touches it.
Zero-byte clone	A second cluster booted from the same anchor; it shares storage objects until it writes.
Continuous mode	A background loop that captures anchors on a fixed cadence for low RPO.

Notes & caveats

Tip

For disaster recovery, combine continuous backup with anchors written to two object-storage targets in different regions, so any one of them can boot a fresh cluster on its own. (Cross-region replication is on the roadmap — see Maturity.)

The first query after restore pays a round-trip per block

Lazy hydration means the very first query against a freshly restored cluster fetches the blocks it touches from object storage. For predictable runs right after restore, use the warm-up tools to pre-fetch hot tables.

Cloud Runtime →

Object storage as a tier of the engine, not an external system.

Cloud Arbitrage →

Cheap storage classes chosen automatically within your residency rules.

Storage Overview →

How data is physically stored, tiered, and recovered.