Operations and recovery

Recovery must be designed before failure. A backup file without a restore procedure, version context, and validation result does not prove recoverability.

In this section

• Monitoring: observe runtime state with doctor, status, daily, service status, and release probes.
• Backups: protect identity, configuration, GEP, memory graph, and workspace data separately.
• Incident response: stop impact growth, preserve evidence, and choose a recovery path.

Recovery order

1. Stop new publication, task claims, spending, or automatic writes.
2. Preserve current logs, events, versions, configuration sources, and failure time.
3. Classify the issue as identity, network, asset, process, release, or data related.
4. Restore one minimal instance from a tested backup or rollback path.
5. Re-enable automation gradually after stability is verified.

Do not use repeated restarts as a substitute for classification, and do not repeat a high-impact command when an unknown partial write may already have occurred.

EvoX Docs · Administration · Operations and recovery