Operations
Backup, restore and disaster recovery
Back up Eden control state, encryption material and deployment identities together. Telemetry exports alone cannot restore organizations, RBAC, endpoint credentials or migration authority. An Eden backup does not back up the data in your connected databases.
Recovery inventory
| State | Backup boundary | Recovery consequence |
|---|---|---|
| Single-node Turso control database | Entire stopped /var/lib/eden volume, including database sidecar/WAL files | Organizations, policies, endpoint configuration and migration state |
| DuckDB telemetry and local durable outboxes | Same stopped volume; include custom paths outside it | Retained history and unacknowledged export batches; replay can duplicate delivery |
| HA PostgreSQL control and DBOS databases | Provider-consistent database backup/PITR, including every configured database | Control authority, workflow history and durable migration checkpoints |
| HA replica state | Each process-exclusive volume separately, with its ordinal/identity recorded | Outboxes and HA stores; a copied volume is not a new replica identity |
| ClickHouse and external audit sinks | Backend-native backup and retention policy | Historical telemetry/audit evidence; independent from live migration authority |
| Application keys, license and HA identities | Encrypted secret-manager backup separate from data backups | Existing encrypted credentials and signed identities remain usable |
| Chart, values, configuration, image digest | Private versioned deployment record without plaintext secrets | Reproducible deployment and schema/version identification |
Include EDEN_DB_ENCRYPTION_KEY, any per-organization wrapping keys or KMS key references, JWT/bootstrap secrets, stable deployment UUID, node identities, offline lease/trust inputs, and HA signing/TLS keys where used. Record their secret versions without including the values in a diagnostic bundle. Retain custom EDEN_TURSO_PATH, DuckDB, outbox, DBOS and HA state locations in the inventory. Files outside the default volume need separate coverage.
Back up an embedded deployment
- Record the image digest, product version, values and backup timestamp. Stop
new application traffic and control mutations. Inspect active migrations; finish or deliberately pause them and record their durable operation state.
- Stop Eden gracefully and wait for the process and pod to exit. For the
single-node release from the installation guide:
```bash kubectl -n eden scale deployment/eden --replicas=0 kubectl -n eden wait --for=delete pod \ -l app.kubernetes.io/instance=eden --timeout=120s
```
For Compose, use docker compose -f docker-compose.single.yaml stop eden. Disable automatic reconciliation that could start a second writer during the backup window.
- Take a complete storage-provider snapshot or offline copy of the mounted
state volume. Preserve ownership, file modes and every database sidecar. A copy of a live .db file alone is not this backup procedure.
- Encrypt the backup, record its checksum/provider snapshot identifier and
keys' versions, then start the original process (kubectl -n eden scale deployment/eden --replicas=1 for that release). Verify /health, /ready and an authorized read before restoring normal traffic.
- Restore the backup in an isolated exercise and measure recovery time. A
successful snapshot operation without a restore exercise is insufficient.
Restore an embedded deployment
Fence the original writer first, including any restart controller. Restore to an empty replacement volume while Eden is stopped. Install the same image digest, configuration, original encryption key and deployment identity; mount the restored volume at the original paths with the expected file ownership. Start exactly one process, with application traffic still blocked.
Check liveness/readiness, organization and endpoint inventory, RBAC, credential decryption and backend connectivity. Send a controlled read/write round trip to a disposable endpoint. Confirm outboxes replay and drain; the durable exporters provide at-least-once delivery, so downstream duplicates can occur. Do not start two active embedded containers from copies of the same snapshot.
Inspect each interrupted migration's operation, terminal reason and restart fences before attempting recovery. A restored database cannot prove whether external writes completed after the backup. Preserve source authority and use migration recovery to reconcile uncertain effects. Restoring an old checkpoint is not permission to replay an ambiguous write or complete cutover.
Offline license watermarks and HA accepted configuration generations enforce anti-rollback. Preserve their current trusted state; do not delete or rewind them to make an old backup start. A restore that conflicts with these checks requires valid replacement authority/identity inputs before admission.
Recover an HA deployment
Use the PostgreSQL provider's tested cluster backup/PITR procedure. PITR requires a base backup and the continuous WAL sequence; configuration and secret files need separate backups. See the PostgreSQL recovery documentation.
Fence the old Eden fleet before restoring control authority to a new database timeline. Restore all control/workflow databases to a mutually consistent boundary, then recover the Eden identities and each volume under the HA deployment contract. Never merge divergent control databases or copy one replica's HA store into another ordinal. Validate consensus, membership, cache-sync and migration participant digests before admitting traffic.
ClickHouse restoration is independent. Recover retained analytics and audit history using the provider's procedure, then reconcile duplicate outbox replay and any retention gap. Optional telemetry-query unavailability does not erase durable migration authority; it also cannot supply missing safety evidence.
Set and exercise recovery objectives
Choose RPO from the frequency/retention of recoverable backups and archived writes, and RTO from a measured restore exercise. Record the restore target, fencing action, recovery point, unavailable history, validation results and traffic admission decision. Exercise lost-volume, lost-database, lost-secret and interrupted-migration scenarios separately. No universal RPO or RTO is implied by the deployment profile.