Backup & availability
How the managed Evitrus cloud on evitrus.io is backed up, and what recovery targets apply during closed beta. These figures are operating targets, not a contractual high-availability commitment.
Current posture
Evidence Events live in an append-only event store in the cluster; identity and overlays live on Postgres volumes. Volumes use provider-managed disk encryption. The stack can be rebuilt from infrastructure-as-code and pinned container images. There is not yet a customer-facing point-in-time restore product.
Target objectives (beta)
| Metric | Target | Comment |
|---|---|---|
| RPO | ≤ 24 hours | Daily volume snapshots / host backups as configured on the cluster |
| RTO | ≤ 24 hours | Redeploy stack and restore volumes; best-effort for beta |
| Restore testing | At least annually | Restore drills are logged internally; quarterly is the target for general availability |
Evidence platforms should assume customers also keep an independent copy via Data portability for long-term exit and offline retention.
Business continuity
On a prolonged outage beyond the RTO target, the incident lead follows incident response, communicates status to affected organisation admins, and restores from the latest good snapshot where possible. If snapshots are unusable, the stack is rebuilt from git and customers can re-ingest from their own exports.
What improves for general availability
Documented snapshot schedules with automated failure alerts, tighter RPO/RTO with highly available Postgres and the event store, and optional customer-held export jobs are planned as the paid service matures. See also Scale & SLOs.