11.1 백업 전략 결정

운영 PostgreSQL의 백업 전략은 데이터 손실 허용량(RPO)과 복구 시간 허용량(RTO), 그리고 보존 기간으로 결정됩니다. PostgreSQL은 두 갈래 — 논리 백업(pg_dump)과 물리 백업(pg_basebackup·pgBackRest·Barman)을 모두 지원합니다. 둘의 차이와 의사결정 기준을 정리합니다.

논리 vs 물리

의사결정

    flowchart TD
  Q1{"보호 요구"}
  Q1 -- "최근 N시간 손실 OK" --> LOGICAL["pg_dump<br/>(주기 스냅샷)"]
  Q1 -- "초 단위 손실까지 방어" --> PITR["pg_basebackup + WAL archive<br/>또는 pgBackRest"]

  Q2{"버전 마이그레이션"}
  Q2 -- "메이저 업그레이드 도구" --> LOGICAL2["pg_dump 또는 logical replication"]
  Q2 -- "같은 메이저 내 이동" --> PHYSICAL["physical"]

  Q3{"클러스터 규모"}
  Q3 -- "< 50GB" --> EITHER["둘 다 OK"]
  Q3 -- "> 500GB" --> PHYSICAL3["physical (pgBackRest/Barman)"]

  classDef log fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
  classDef phy fill:#d1fae5,stroke:#047857,color:#064e3b
  classDef q fill:#fed7aa,stroke:#c2410c,color:#7c2d12
  class LOGICAL,LOGICAL2,EITHER log
  class PITR,PHYSICAL,PHYSICAL3 phy
  class Q1,Q2,Q3 q
  

운영 표준 권장:

RPO·RTO 매트릭스

3-2-1 규칙

• 3 카피
• 2 다른 매체
• 1 오프사이트

PostgreSQL 환경 매핑:

• primary 데이터 + standby + archive — 3 카피
• 로컬 디스크 + 외부 객체 저장소 — 2 매체
• 다른 리전 또는 cold storage — 오프사이트

운영 사고의 70%는 3-2-1 미준수에서 시작합니다. “어제 백업했는데 백업 디렉토리가 같은 디스크에 있었다” 같은 사례가 흔합니다.

WAL archive의 역할

물리 백업의 핵심은 기준 백업 + 그 이후의 WAL. WAL이 누락되면 base 백업 시점까지밖에 복구 못 함 → RPO 큽니다.

archive_command가 계속 성공해야 PITR이 의미.

SELECT * FROM pg_stat_archiver;
-- last_archived_wal, last_failed_wal, last_failed_time

last_failed_time이 last_archived_time보다 늦으면 archive 실패 후 미복구 — 즉시 대응합니다.

백업 자체의 검증

가장 자주 잊는 단계. 백업이 복원 가능한지를 정기 확인하지 않으면 필요할 때 실패합니다.

“백업이 있는가"가 아니라 “방금 복원 시도가 성공했는가"가 진짜 지표

저장 위치

pgBackRest는 S3·Azure·GCS·SFTP 다 직접 지원합니다. Barman은 SSH/SFTP 기반입니다.

보존 정책

pgBackRest의 expire 명령 또는 Barman의 retention_policy가 자동 정리합니다.

흔한 사고 패턴

정리

• 백업 결정 = RPO + RTO + 보존 정책의 함수
• 운영 표준은 pgBackRest 또는 Barman + WAL archive 연속
• 작은 DB·마이그레이션엔 pg_dump 적절, 큰 DB·PITR 필요는 물리
• 3-2-1 규칙: 3 카피, 2 매체, 1 오프사이트
• WAL archive 실패는 즉시 알람 — pg_stat_archiver.last_failed_time
• 복원 검증이 진짜 지표 — “방금 복원 성공했나”

다음 절(11.2)에서는 가장 단순한 백업 도구 — **pg_dump / pg_restore**를 봅니다.