How TurboFinOps protects customer data and restores service in the face of infrastructure failures, accidental deletion or large-scale provider outages.
| Objective | Target | Definition |
|---|---|---|
| RPO — Recovery Point Objective | ≤ 24 hours | Maximum acceptable data loss measured from the last successful backup. |
| RTO — Recovery Time Objective | ≤ 24 hours | Target time to restore service from a region-level failure for the control plane. |
| Backup retention | 30 days rolling | Logical backups retained for 30 days; point-in-time recovery available within the provider window. |
| Restore test cadence | Quarterly | A randomly selected backup is restored to an isolated environment and validated against integrity checks. |
These are operational targets, not contractual guarantees unless mirrored in an executed Order Form or DPA addendum. Enterprise customers may negotiate stricter terms.
| Data class | Protection | Recovery target | Region |
|---|---|---|---|
| PostgreSQL (Supabase) | Point-in-time recovery + daily logical backup | 24 h (logical) / minutes (PITR) | EU (Frankfurt) by default; isolated backup region. |
| Redis (Aiven) | Replicated cache. Treated as ephemeral; no source of truth. | n/a | Rebuilt from PostgreSQL on restart. |
| Object storage (evidence, exports) | Versioned objects with delete protection on production buckets | 24 h | Same-region replicated; cross-region copy on roadmap. |
| Application code and infrastructure | Git-versioned in source control; reproducible builds from main branch | minutes | Rebuild from CI; container images stored in registry. |
Automated checks confirm the latest backup completed, was non-empty and matches expected schema. Failures page the on-call engineer.
A backup is restored to a sandbox, schema is validated, and a representative tenant subset is queried to confirm referential integrity.
Documented step-by-step procedure to restore the control plane in a secondary region using the latest available backup and the Git-versioned infrastructure definitions.
Service credentials and signing keys are rotated on any restore that crosses a confidentiality boundary; customers are notified if their integrations require re-authentication.
TurboFinOps is a control plane; customer cloud accounts remain authoritative for the resources they host. A complete loss of TurboFinOps state would not affect customer cloud resources directly, and inventory could be rebuilt by re-scanning the connected accounts. Savings receipts, audit logs and findings older than the restored backup window may be lost.
Audit logs and evidence artifacts can be exported on a recurring schedule (see reporting and exports) so that critical compliance evidence is held in customer-controlled storage.
Connect one AWS, Azure or GCP scope, approve the safest savings actions, and give finance a receipt when the savings verify.