1.1 Failure model과 복구 단위
Backup 방식은 실패 종류와 복구 단위에 맞춰 선택합니다. 하나의 backup으로 모든 사고를 가장 빠르게 복구하기는 어렵습니다.
| 실패 | 필요한 복구 단위 | 적합한 수단 |
|---|---|---|
| 실수로 table 삭제 | database, object, 시점 | logical restore 또는 PITR 후 추출 |
| Data directory 손실 | cluster 전체 | physical backup + WAL |
| Primary host 장애 | service | replica failover |
| Region 장애 | service와 data | off-site backup, standby, DNS 전환 |
| Credential 유출 | trust boundary | 격리된 immutable backup과 key rotation |
| 논리적 손상 전파 | 과거의 정상 시점 | 보존된 backup + PITR |
Replica는 최신 상태를 빠르게 제공하지만 DROP TABLE과 잘못된 UPDATE도 복제합니다. Backup은 과거 상태를 보존하지만 service 전환을 자동화하지 않습니다.
Dependency inventory
PostgreSQL data만 복구해도 application이 시작되지 않을 수 있습니다. 다음 항목을 함께 관리합니다.
- Role, password policy,
pg_hba.conf, TLS certificate - Tablespace와 mount path
- Extension package와 shared library
- Encryption key와 secret manager 접근
- Connection endpoint와 application configuration
- Schema migration version
복구 runbook에는 각 dependency의 owner와 복구 순서를 적습니다. Managed service라면 provider가 보장하는 backup 범위와 사용자가 별도로 보존할 범위를 계약과 실제 restore test로 확인합니다.