Backup and DR policy
Policy requirements
- Critical services and data stores have documented owners, dependencies, backup mechanisms, retention, recovery priorities, and approved recovery objectives.
- Backup access is restricted to authorised provider administrators and protected with MFA.
- Database, object storage, static releases, serverless code, configuration, secrets, and external transaction records are assessed separately; one provider backup does not cover every plane.
- Backups are encrypted in transit and at rest where supported and are monitored for failure.
- Recovery procedures include incident control, evidence preservation, authorisation, communication, integrity validation, security validation, and external reconciliation.
- Restore tests occur at least annually and after material architecture changes; critical recovery paths are tested more frequently where risk requires it.
- Test results record selected recovery point, actual recovery time, data loss, failures, corrective actions, and approval.
- Destructive restoration is never performed solely as a test against production.
Current baseline
Supabase Pro provides automatic daily database backups with seven-day availability according to current provider documentation. Cloudflare Pages maintains successful production deployments that can be selected for rollback. Storage objects require separate protection because database restoration restores their metadata, not deleted object content.
Recovery-objective governance
RPO and RTO are business decisions. Until formally approved and tested, provider retention and rollback capability are described as capabilities rather than contractual recovery objectives. Business owners own the maximum tolerable data-loss and downtime decision for critical workflows. Approved values are not currently available.
Recovery-tier model
| Tier | Business effect | Recovery design |
|---|---|---|
| Tier 1 | Authentication, tenant isolation, critical policy state, or financial integrity prevents safe operation | Highest-priority recovery, explicit write freeze, database and configuration validation, management communication, and transaction reconciliation |
| Tier 2 | Core customer, task, document, quote, or provider workflow is materially degraded | Restore after Tier 1 integrity is established; use controlled manual workaround only when it preserves attribution and reconciliation |
| Tier 3 | Reporting, analytics, non-critical automation, or secondary operational convenience is unavailable | Recover after transactional workflows; rebuild derived views from authoritative records where possible |
| Tier 4 | Replaceable static, cached, or non-authoritative content is unavailable | Rebuild or redeploy from approved source without treating it as a data restore |
Exercise protocol
The exercise defines a plausible failure, selected recovery point, authorised operators, protected test environment, expected data-loss window, target recovery time, validation queries, application workflows, provider reconciliation, and abort conditions. It records actual start and finish times, restored point, failed steps, security checks, business-owner acceptance, and corrective actions. A provider backup listing alone is not a recovery exercise.
Current-state limitation
No approved RPO/RTO matrix, current backup export, PITR confirmation, object-backup evidence, or completed restore exercise was available. These are required follow-up evidence, not assumed controls.