Recovery Operations Policy

Purpose & Scope

This policy defines how Ekosistem App recovers from incidents that affect availability or data integrity, including infrastructure outages, accidental deletion, corruption and security incidents.

Backups & Targets

Recovery objectives and the backups that support them:

• Postgres on Supabase: managed daily backups with point-in-time recovery (PITR) on plans that support it.
• R2 object storage: versioning enabled where supported; deletions retained per provider lifecycle policies.
• Redis: ephemeral by design — rate-limit counters, JWT blacklist and caches are rebuilt automatically.
• Application code: source of truth in Git; deploy artefacts on Railway and Vercel are immutable per release.
• RPO target: ≤ 24 hours for application data; RTO target: ≤ 4 hours for full service restoration in a SEV1 outage.

Recovery Procedures

Recovery follows defined runbooks per failure mode:

• API outage — redeploy from a known-good main commit on Railway; restore environment from secret store.
• Web outage — redeploy from a known-good main commit on Vercel; verify static assets and edge cache.
• Data loss — restore Postgres from the most recent backup or PITR; reapply migrations from Drizzle history if required.
• Object storage corruption — restore object versions from R2; revoke any active signed URLs that may reference corrupt objects.
• Secret compromise — rotate JWT, refresh, magic-link, R2, SES, Redis and provider tokens; force re-auth via blacklist.

Testing & Exercises

Recovery readiness is validated regularly:

• Restore-from-backup is exercised in a non-production database at least quarterly.
• Redeploy procedures are exercised whenever Railway or Vercel introduce platform changes.
• Secret rotation is exercised at least annually.
• Tabletop exercises cover compound failures (e.g. provider outage + data loss).

Review & Contact

This policy is reviewed at least annually, after every recovery exercise and after every SEV1 incident. Comments to developer@plademy.com.