11장. 백업과 PITR — "어제 오후 1시 59분으로 되돌려 주세요"

실수로 DROP TABLE을 날린 순간에도 살아날 길은 있습니다. 베이스 백업 + WAL 아카이브의 조합으로 원하는 시점을 정확히 재현하는 Point-In-Time Recovery를 배웁니다.

11.1 백업의 두 축 — SQL로 다시 만들기 vs 바이트로 되살리기

PostgreSQL 백업은 성격이 전혀 다른 두 축으로 나뉩니다. 논리 백업은 "테이블을 다시 만들 수 있는 SQL"을 뽑아내고, 물리 백업은 "데이터 디렉터리 자체"를 바이트 단위로 복사합니다.

# 논리 백업 — custom 포맷(-Fc)이 가장 권장: 선택적·병렬 복구 가능
pg_dump -h db.example -U postgres -Fc -f app.dump app
pg_dumpall --globals-only > globals.sql          # 롤·전역 객체 (필수!)

# 복구 — 병렬 8개로
pg_restore -d app_restored --jobs=8 app.dump
# 복구 후 반드시 ANALYZE — 통계 없으면 플랜이 망가진다

11.2 PITR의 재료 — 베이스 백업 + WAL 아카이브

PITR(Point-In-Time Recovery)의 원리는 9장의 크래시 리커버리와 똑같습니다. 다른 점은 단 하나 — "어느 시점의 데이터 파일 + 어디까지의 WAL"을 우리가 고른다는 것. 그러려면 두 가지 재료를 상시 준비해야 합니다.

1. 베이스 백업 — 특정 시점의 데이터 디렉터리 스냅샷 (pg_basebackup, 주 1회 등)
2. WAL 아카이브 — 그 이후 생성된 모든 WAL 세그먼트의 영구 보관

# postgresql.conf — 아카이브 활성화
wal_level = replica              # minimal은 아카이브 불가
archive_mode = on                # 변경 시 재시작 필요
archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'
# %p = WAL 파일 경로, %f = 파일명. 0 리턴 = 성공

# 베이스 백업 (주기 실행)
pg_basebackup -h primary.example -U replicator \
  -D /backup/base_$(date +%Y%m%d) \
  -Ft -z -X stream -P              # tar+gzip, 백업 중 WAL 동시 수집

11.3 PITR — 시간을 되감는 타임라인

시나리오: 4월 23일 14:00, 누군가 운영 DB에 실수로 DROP TABLE orders를 실행했습니다. 마지막 베이스 백업은 4월 20일. 목표는 사고 1분 전인 13:59로 되돌리는 것입니다.

실제 절차는 설정 몇 줄입니다 (v12+ 기준 — recovery.conf는 v12에서 제거되었습니다).

# 1) 데이터 디렉터리 비우고 base backup 복원
pg_ctl stop -D $PGDATA && rm -rf $PGDATA/*
tar -xf /backup/base_20260420.tar -C $PGDATA

# 2) postgresql.conf에 복구 타겟 지정
restore_command = 'cp /archive/%f %p'
recovery_target_time = '2026-04-23 13:59:00+09'
recovery_target_action = 'pause'     # pause | promote | shutdown

# 3) recovery.signal 생성 후 기동
touch $PGDATA/recovery.signal
pg_ctl start -D $PGDATA

-- 4) 타겟 도달 후 데이터 확인 → 서비스 오픈
SELECT pg_wal_replay_resume();   -- 또는 pg_promote()

11.4 아카이브가 조용히 실패하고 있다면

PITR 체계의 최대 적은 화려한 장애가 아니라 조용한 실패입니다. archive_command가 0이 아닌 값을 반환하면 PostgreSQL은 해당 WAL을 pg_wal/에 계속 보관하며 재시도합니다 — S3 인증 만료, 디스크 풀, 네트워크 단절이 흔한 원인입니다. 눈치채지 못하면 두 가지 재앙이 동시에 옵니다: 복구 가능 시점이 멈추고(RPO 파괴), pg_wal이 차올라 서버가 PANIC 정지합니다.

-- 아카이버 건강 검진 — failed_count는 꾸준히 0이어야 한다
SELECT archived_count, failed_count,
       last_archived_wal, last_archived_time,
       last_failed_wal, last_failed_time
FROM pg_stat_archiver;

11.5 RPO / RTO — 그리고 "복구해본 적 없는 백업은 백업이 아니다"

백업 설계의 언어 두 가지: RPO(Recovery Point Objective — 어디까지의 데이터를 잃어도 되는가)와 RTO(Recovery Time Objective — 얼마나 빨리 복구해야 하는가)입니다. 구성에 따른 대략의 수준은 이렇습니다.

✍️ 이해도 체크