This plan describes Cortena's approach to service recovery following disruptions, outages, or disaster scenarios.
1. Purpose
To ensure that Cortena can restore production services in a controlled, predictable, and documented manner following any significant disruption.
2. Scope
Applies to production services and supporting infrastructure, including core application services, databases, file/object storage, and third-party integrations.
3. Recovery targets
| Metric | Target | Description |
|---|---|---|
| RTO (Recovery Time Objective) | 4 hours | Maximum time to restore critical services after a disruption is declared |
| RPO (Recovery Point Objective) | 24 hours | Maximum data loss window · the furthest back we may need to restore from backup |
These targets are reviewed periodically and updated as the platform scales.
4. Recovery approach
4.1 Backup and restoration
- Backups are maintained for all critical data stores (databases and object storage)
- Backup integrity is tested periodically to verify recoverability
- Restoration follows internal runbooks maintained by the CTO
- See Backup and retention for retention periods
4.2 Infrastructure recovery
- Production services run on a private Kubernetes cluster (Hetzner, Germany)
- Services are restored using controlled, versioned deployment processes via CI/CD
- Infrastructure-as-code ensures environments can be rebuilt consistently
4.3 Monitoring and validation
- Monitoring and logging (Grafana, Sentry) are used to detect disruptions and validate recovery
- Service health is confirmed before declaring recovery complete
- Recovery actions are documented in the incident report
5. Dependencies
Recovery may involve coordination with sub-processors where applicable:
- Hetzner (hosting infrastructure)
- Yapily (banking connectivity, if enabled)
- OpenAI (LLM processing, if affected)
See Sub-processors for details.
6. Roles during recovery
| Role | Responsibility |
|---|---|
| CTO | Leads technical recovery, coordinates infrastructure restoration |
| CEO | Manages customer communication and contractual implications |
| Engineering | Executes restoration runbooks, validates service health |
7. Plan review
This plan is reviewed periodically and updated following any major incident or material change to the platform infrastructure.