Skip to content

Disaster recovery

Venturi’s disaster-recovery posture protects your attribution records, event history, audit log, configuration, and the serving plane that exposes them. It is built on a single, propagated recovery pair (RPO ≤ 15 minutes, RTO ≤ 1 hour), underwritten by an event-sourcing design that makes most of the system a derived artifact you can rebuild from a durable source of truth.

Disaster recovery in one page

  • RPO ≤ 15 minutes: the maximum data you could lose in a recovery event.
  • RTO ≤ 1 hour: the maximum time to restore the serving plane.
  • One pair, propagated identically across every store: no confusing per-component variation.
  • Recovery does not stop your AI traffic. The fail-open decision-time interceptor forwards live requests unmodified while the Venturi dependencies behind it are recovering.

Recovery objectives

Objective Target Scope
Recovery point objective (RPO) ≤ 15 minutes Maximum data loss across tenant attribution stores and event logs
Recovery time objective (RTO) ≤ 1 hour Time to restore the serving plane
Decision-time interceptor behavior during recovery Fail-open Customer AI traffic is forwarded unmodified throughout

This RPO/RTO pair is propagated identically everywhere, so you reason about one recovery objective pair, not a matrix of per-store numbers. It applies on every support tier as a platform objective, not as a per-tier commitment in Commitments by support tier. Your order form is the commercial authority for any customer-specific binding recovery commitment.

Recovery does not stop your AI traffic

A disaster-recovery event degrades your visibility into attribution for a bounded window; it does not stop your production inference. Because the decision-time interceptor is fail-open within its 50 ms P99 end-to-end budget, live AI requests that reach it are forwarded unmodified while the stores behind it are restoring. The RTO governs how long until you can read Venturi again, not how long your AI is down. If your requests route through the drop-in proxy, the proxy endpoint’s own reachability stays on your request path; see Proxy endpoint reachability.

The recovery design: event sourcing

The reason the RPO can be tight is architectural. Venturi treats the durable, replicated invocation log as the source of truth, and the attribution graph and the materialized index as derived projections of it. That gives every store a recovery story matched to its role.

Store Role Recovery
Invocation log Durable, ordered, replicated source of truth Writes are acknowledged only after replication across availability zones, so node or zone loss loses no committed event; tiered storage retains history for disaster recovery
Attribution graph Resolved identity → organization → budget structure Restored from snapshot or fully rebuilt by replaying the invocation log, within 30 minutes
Materialized index Fast read surface for dashboards and the API Architecturally rebuildable; reconstructed from the graph within 60 seconds, no separate backup required
Object storage Audit log, billing reports, export artifacts High intrinsic durability with versioning enabled; the audit log is also under Object Lock with a 5-year retention period

Because the graph and index are derivable, a catastrophic loss of a serving store is recovered by replay, not by hoping a single backup is intact; the durable log lets Venturi reconstruct attribution deterministically up to the recovery point.

Backup and restore

  • Automated backups cover every persistent store: the event log, the attribution graph, configuration, audit log, and export metadata.
  • Backups are encrypted and locked. Every backup is encrypted at rest with your tenant’s customer-managed key, written to object-locked storage that rejects deletion or tampering during its retention window, and integrity-checked when it is created and again before any restore.
  • Topology. Every stateful tier (the relational store, the event log, the graph, the index, and object storage) spans at least two availability zones inside your residency region, so the loss of one zone loses no committed event. Single-region is the default; cross-region replication of object storage and the audit trail, and regional failover, are available under agreement and never move data across a residency boundary.
  • Cadence. Backup schedules are set per store to meet the 15-minute RPO. The invocation log is replicated continuously and keeps its history in tiered storage, so replaying it gives a recovery point of zero within its retention window. The attribution graph is also snapshotted daily, and object storage keeps prior object versions.
  • Retention. Graph snapshots are kept for 7 days, because the invocation log is the preferred recovery source. Every other backup follows a declared, configurable retention policy bounded by your data-retention setting (13 months by default), and crypto-shred erasure reaches backups within the 30-day erasure window. The audit log keeps its separate 5-year Object Lock retention.
  • Your deployment’s values. The activation record names the regions and availability zones, replication mode, backup schedule, retention window, and restore source for your deployment.
  • Restores are validated before the service is marked healthy. A restore verifies both data integrity and tenant isolation: a recovered serving plane is never returned to service until cross-tenant boundaries are confirmed intact. Tenant isolation fails closed during recovery exactly as it does in normal operation.
  • The audit log is preserved across recovery. Backup and restore operations are themselves recorded, so the append-only, object-locked audit trail spans recovery events. See Audit logs.

Crypto-shred erasure survives recovery

A subject erased by crypto-shred stays erased after a restore: the per-subject key is destroyed, so the subject’s content is cryptographically unrecoverable even from backups. Recovery restores the system to a consistent state; it does not resurrect data that was lawfully erased.

Rehearsal and evidence

Recovery is rehearsed on a fixed minimum cadence and after any material recovery-design change:

  • Backup restore tests at least quarterly.
  • A full disaster-recovery drill at least every 6 months that restores from backup into an isolated environment and compares the measured recovery time and recovery point against the published RTO and RPO. A failed or skipped drill pages on-call and opens a tracked finding.
  • Resilience game days at least every 6 months, exercising dependency failures and stateful-tier failover.

Your order form can require a more frequent cadence. The procedure is documented and rehearsed, not assumed. Each rehearsal produces a dated pass/fail record with evidence you can review:

  • Timestamps for the recovery run.
  • The components restored.
  • Validation results: integrity and tenant-isolation checks.
  • Any corrective actions taken.

This rehearsal evidence is part of Venturi’s availability and recovery posture and is available through the Trust center for security and procurement review.

The order form is the commercial authority for customer-specific commitments. The activation record and recovery runbook are the technical authority for the topology, backup cadence, retention, and test evidence of the deployed tenant.

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details 
Docs feedback: Disaster recovery
Page: https://docs.venturi.systems/operations/disaster-recovery/