11.1 백업 전략 결정
운영 PostgreSQL의 백업 전략은 데이터 손실 허용량(RPO)과 복구 시간 허용량(RTO), 그리고 보존 기간으로 결정됩니다. PostgreSQL은 두 갈래 — 논리 백업(pg_dump)과 물리 백업(pg_basebackup·pgBackRest·Barman)을 모두 지원합니다. 두 방식은 복원 속도, PITR 가능 여부, 메이저 버전 간 이동에서 갈립니다.
논리 vs 물리
| 측면 | 논리 백업 | 물리 백업 |
|---|---|---|
| 단위 | SQL/COPY 텍스트 또는 custom 포맷 | 페이지 그대로 + WAL |
| 도구 | pg_dump, pg_dumpall | pg_basebackup, pgBackRest, Barman |
| 크기 | 보통 작음 (압축) | 원본 + WAL |
| 복원 시간 | 느림 (SQL 재실행, 인덱스 재생성) | 빠름 (페이지 복사) |
| PITR | 불가능 (스냅샷 시점만) | 가능 (WAL 재생) |
| 클러스터 vs DB | DB 1개 단위로 가능 | 클러스터 전체 |
| 메이저 버전 간 이동 | 가능 | 불가 (같은 메이저만) |
| 일부 테이블만 | 가능 (-t orders) | 불가 |
| 운영 부하 | 큰 테이블은 부담 | base 백업 1회, 그 후 WAL 누적은 가벼움 |
의사결정
운영 표준 권장:
| 시나리오 | 백업 전략 |
|---|---|
| 일반 운영 | pgBackRest (또는 Barman) 일별 풀 + 시간별 증분 + WAL archive 연속 |
| 작은 DB (< 50GB) | nightly pg_dump + 14일 보존 가능 |
| 마이그레이션·테스트 환경 복제 | pg_dump (custom format) |
| 클라우드 매니지드 | 클라우드 자체 백업 (RDS automated backups 등) |
| 컴플라이언스 — 장기 보존 | physical 백업 + 외부 cold storage (S3 Glacier) |
RPO·RTO 매트릭스
| RPO 요구 | RTO 요구 | 권장 |
|---|---|---|
| 24h | 시간 단위 | 일일 pg_dump |
| 1h | 시간 단위 | pg_basebackup + WAL archive |
| 분 단위 | 분 단위 | 동기 standby + WAL archive |
| 초 단위 | 초 단위 | 동기 standby + failover 자동화 |
| 0 (무손실) | 초 단위 | 동기 quorum 복제 + 자동 failover |
3-2-1 규칙
- 3 카피
- 2 다른 매체
- 1 오프사이트
PostgreSQL 환경 매핑:
- primary 데이터 + standby + archive — 3 카피
- 로컬 디스크 + 외부 객체 저장소 — 2 매체
- 다른 리전 또는 cold storage — 오프사이트
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가 실패한 뒤 복구되지 않은 상태이므로 즉시 대응합니다.
백업 자체의 검증
가장 자주 잊는 단계입니다. 백업이 복원 가능한지를 정기적으로 확인하지 않으면 정작 필요할 때 실패합니다.
| 검증 빈도 | 방법 |
|---|---|
| 매주 | pg_dump 결과를 빈 인스턴스에 restore — 자동화 |
| 매월 | 물리 백업 PITR을 staging에서 실제 실행 |
| 매분기 | 운영자가 DR 시나리오 시뮬레이션 (역할 분담 포함) |
백업 상태는 백업 파일의 존재보다 최근 복원 시도의 성공 여부로 판단합니다.
저장 위치
| 위치 | 용도 |
|---|---|
| 로컬 NVMe | 빠른 backup write, 임시 |
| 같은 호스트의 별 디스크 | 빠른 복구 |
| 외부 NFS/네트워크 스토리지 | 호스트 망 시 안전 |
| S3 / NCP Object Storage / Azure Blob | 오프사이트 표준 |
| Glacier / Archive tier | 장기 보존 (저렴) |
pgBackRest는 S3·Azure·GCS·SFTP 다 직접 지원합니다. Barman은 SSH/rsync 또는 streaming으로 수집하고, 클라우드 저장소는 barman-cloud 도구로 지원합니다.
보존 정책
| 카테고리 | 일반 |
|---|---|
| nightly | 14~30일 |
| weekly full | 3개월 |
| monthly | 1년 |
| yearly | 7년 (컴플라이언스 요구) |
pgBackRest의 expire 명령 또는 Barman의 retention_policy가 자동 정리합니다.
흔한 사고 패턴
| 사고 | 원인 | 예방 |
|---|---|---|
| 백업 디스크가 데이터와 같이 망함 | 단일 디스크 | 오프사이트 |
archive_command 실패가 모르게 누적 | 모니터링 부족 | pg_stat_archiver 알람 |
| pg_dump 30분 걸린다고 새벽에만 돌림 | RPO 24h | 물리 백업으로 전환 |
| 복원 절차 문서가 옛 버전 | 검증 안 함 | 분기 DR 훈련 |
| 매니지드 백업만 믿음 | 클라우드 사고 가능성 | 외부 dump 보조 |
클라우드 매니지드의 자동 백업도 클라우드 콘솔 안에 있습니다. 계정 사고·삭제·리전 장애 시 같이 사라집니다. 외부 객체 저장소로 별도 dump가 컴플라이언스의 표준입니다.
정리
- 백업 결정 = 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로 즉시 알람을 걸어야 합니다.