Backup & Recovery Policy¶
| Field | Value |
|---|---|
| Status | draft |
| Owner | OPS |
| Applies to | Production GCP data stores (Cloud SQL Postgres, Memorystore Redis), critical configuration/state, and the Git repositories that hold all source and governance evidence. |
| Review cadence | Annual; plus after any restore drill or recovery event. |
| Mapped controls | OPS-01 (backups + restore drills), OPS-03 (DR/failover with RTO/RPO). |
| Evidence | partile-ops: infra/envs/prod-gcp/; ../technical/infrastructure-and-deployment.md; ../registers/action-register.md; ../procedures/incident-response-playbook.md (recovery linkage). |
| Exception handling | A data class excluded from backup is a dated DIR/OPS decision with rationale. |
Purpose¶
Ensure Partile can recover its data and service after loss or corruption, and state honestly what is implemented versus still untested.
Current honest state¶
- GCP production exists, but no real user data has launched. Cloud SQL automated backups and point-in-time recovery are configured (OPS-05), but a restore drill has not yet been run (OPS-01 / ACT-005).
- DR/failover is not started (OPS-03). Current Cloud SQL is the low-cost
ZONALposture and Redis is not yet an HA/SLA posture; ACT-003 tracks the regional/HA upgrade before any production availability SLA. - Redis is ephemeral by design. Memorystore holds OAuth state, handoff codes, and rate-limit counters; it is reconstructable and not a backup target by default.
- Terraform remote state is sensitive operational evidence. The private GCS state bucket may contain generated secret material, so it is Tier 2 and must remain private.
- Today's real recoverable asset is Git. All source, infra-as-code, and this governance evidence live in Git across the idea worktrees, hosted on GitHub — giving distributed copies and full history. That is the de-facto backup of the non-data assets and is operating now.
Requirements¶
- Automated backups of Postgres (point-in-time recovery / daily snapshots) and critical config. Cloud SQL backups/PITR are already configured; keep them enabled before real user data.
- Encryption of backups at rest and in transit (
cryptography-and-secrets- policy.md). - Retention of backups bounded and reconciled with the data retention schedule and erasure obligations — backups must not silently defeat erasure (a deleted user reappearing from a restore is a privacy failure; document the restore-then-re-erase handling). [counsel touchpoint] ties to C4/C5.
- Restore drills at least annually and before public launch — an untested backup is not a backup. Each drill is recorded as evidence for OPS-01 and closes ACT-005 for the relevant environment.
- Targets: define RTO/RPO per data class before public launch (OPS-03). Initial working assumption: RPO ≤ 24h, RTO ≤ 24h for M3; tightened by M5/M6.
Recovery¶
A data-loss or corruption event is an incident (incident-response-policy.md);
recovery follows the playbook and the most recent verified backup. Post-recovery,
reconcile against erasure/retention obligations.
Exceptions¶
Excluding a data class from backup (e.g. fully ephemeral Redis state) is a dated DIR/OPS decision recorded on the OPS-01 control row.