PostgreSQL 17 네이티브 증분 백업 — pg_basebackup 체인 운영과 복구의 현실

PostgreSQL 16까지 pg_basebackup은 언제나 전체 백업만 뽑아냈습니다. 수백 GB짜리 DB를 매일 밤 통째로 복사하는 게 불편하다면 pgBackRest, Barman, WAL-G 같은 외부 도구를 붙이는 수밖에 없었죠. 저도 처음 프로덕션 PostgreSQL을 맡았을 때 "왜 기본 도구에는 증분 백업이 없지?"라는 의문을 품고 pgBackRest 문서를 뒤적였던 기억이 납니다.

PostgreSQL 17 GA와 함께 이 상황이 바뀌었습니다. pg_basebackup에 --incremental 플래그가 추가되고, 체인을 병합하는 pg_combinebackup이 함께 등장했습니다. 외부 도구 없이 PostgreSQL 자체에서 네이티브 증분 백업을 돌릴 수 있게 된 것입니다.

이 글은 2026년 기준으로 이 기능을 프로덕션에서 굴려볼 만한지, WAL Summarizer의 오버헤드부터 체인 관리의 함정까지 실무 관점에서 정리해봅니다. 결론부터 말하면 "쓸 만하다, 다만 조건이 있다"입니다.

어떻게 동작하는가 — WAL Summarizer와 backup_manifest

WAL Summarizer

증분 백업의 핵심 질문은 하나입니다. "마지막 백업 이후 어떤 블록이 바뀌었는지 어떻게 알지?" PostgreSQL 17은 WAL Summarizer라는 백그라운드 프로세스로 이 문제를 해결합니다.

summarize_wal = on을 설정하면 PostgreSQL이 WAL 로그를 분석해 변경된 데이터 블록 목록을 $PGDATA/pg_wal/summaries/ 아래에 기록합니다. 이 요약 파일이 있어야 pg_basebackup --incremental이 "어떤 블록을 가져가야 하는지" 판단할 수 있습니다.

-- summarize_wal은 SIGHUP 컨텍스트로, 원칙적으로 reload로 반영됩니다.
-- 다만 환경에 따라 Summarizer 프로세스 상태를 반드시 확인해야 합니다.
ALTER SYSTEM SET summarize_wal = 'on';
SELECT pg_reload_conf();
 
-- Summarizer 상태 확인 (summarized_lsn이 진행하는지 확인)
SELECT * FROM pg_get_wal_summarizer_state();
 
-- 생성된 WAL 요약 파일 목록
SELECT * FROM pg_available_wal_summaries();

pg_get_wal_summarizer_state()에서 summarized_lsn이 현재 WAL 위치를 따라오지 못하면 증분 백업이 실패하거나 예상보다 큰 체인을 만들 수 있으니, 모니터링 대상으로 추가해두는 편이 좋습니다.

backup_manifest

각 백업 디렉터리에는 backup_manifest 파일이 생성됩니다. 파일 경로, 크기, 수정일, 체크섬(CRC32C 또는 SHA 시리즈)이 담깁니다. 증분 백업을 실행할 때 이 파일을 --incremental 옵션에 넘기면, 해당 시점 이후 변경된 블록만 선택적으로 가져옵니다. 체크섬 덕분에 병합 시점에 체인 내 파일 손상을 감지할 수 있습니다.

백업 체인 만들기

포맷 선택 — plain을 권장

pg_combinebackup은 입력으로 plain 포맷의 데이터 디렉터리를 요구합니다. -F tar로 만든 백업은 병합 전에 별도로 풀어줘야 하므로, 증분 체인을 상시 운용할 계획이라면 -F plain(기본값)이 실용적입니다.

# 1. 전체 백업 (체인의 시작점)
# 주의: --checkpoint=fast는 즉시 체크포인트를 강제해 I/O 스파이크를 유발합니다.
#       프로덕션에서는 spread(기본)로 두거나, 부하 낮은 시간에만 fast를 쓰세요.
pg_basebackup \
  -D /backup/full \
  -F plain \
  -P
 
# 2. 첫 번째 증분 백업 (전체 백업의 manifest 참조)
pg_basebackup \
  -D /backup/inc1 \
  --incremental=/backup/full/backup_manifest \
  -F plain \
  -P
 
# 3. 두 번째 증분 백업 (inc1의 manifest 참조)
pg_basebackup \
  -D /backup/inc2 \
  --incremental=/backup/inc1/backup_manifest \
  -F plain \
  -P

증분 백업은 반드시 직전 백업(전체 또는 증분)의 backup_manifest를 참조해야 합니다. 체인 순서가 어긋나면 안 됩니다.

복구: pg_combinebackup으로 병합

증분 백업 파일 자체로는 복구할 수 없습니다. pg_combinebackup으로 전체 백업 + 모든 증분을 하나의 데이터 디렉터리로 합성한 뒤에야 PostgreSQL이 기동될 수 있습니다.

# 전체 백업 + 증분 2개를 하나의 데이터 디렉터리로 병합
pg_combinebackup \
  /backup/full \
  /backup/inc1 \
  /backup/inc2 \
  -o /restore/combined

병합이 끝난 디렉터리는 initdb가 만든 것과 동일한 구조의 완전한 데이터 디렉터리입니다. 이후 절차는 목적에 따라 갈라집니다.

• 크래시 시점까지 복구(가장 최근 WAL 재적용): 별도 신호 파일 없이 그대로 기동해도 되지만, 보통은 restore_command를 설정해 아카이브의 WAL을 순서대로 가져오게 합니다.
• PITR(특정 시점 복구): restore_command와 recovery_target_time(또는 recovery_target_lsn 등)을 postgresql.conf나 postgresql.auto.conf에 설정하고, 데이터 디렉터리에 빈 recovery.signal 파일을 만든 뒤 기동합니다. (PostgreSQL 12부터 recovery.conf는 폐지됐습니다.)
• 스탠바이로 붙이기: primary_conninfo를 설정하고 standby.signal 파일을 만들어 기동합니다.

# PITR 예시 — 병합 디렉터리를 DATA로 옮긴 뒤
cat >> $PGDATA/postgresql.auto.conf <<EOF
restore_command = 'cp /wal_archive/%f %p'
recovery_target_time = '2026-08-27 14:30:00+09'
recovery_target_action = 'promote'
EOF
 
touch $PGDATA/recovery.signal
pg_ctl -D $PGDATA start

증분 백업이 절약해주는 것은 백업 시간과 전송량이지 복구 자체는 아닙니다. 오히려 복구 경로는 pg_combinebackup 병합 단계가 추가되어 전체 백업 하나로 복구할 때보다 길어질 수 있습니다. 실제 복구 시간은 체인 길이, 병합 대상 총 용량, 스토리지 I/O 특성에 크게 좌우되므로, 도입 전 자기 환경에서 반드시 측정해봐야 합니다.

상황별 전략

pg_walsummary — 언제 쓰나

pg_walsummary CLI는 요약 파일이 어떤 릴레이션의 어떤 블록 변경을 담고 있는지 출력해주는 진단 도구입니다. 평상시 운영에서 쓸 일은 거의 없고, 다음과 같은 경우에 유용합니다.

• 증분 백업이 예상보다 커졌을 때, 어떤 릴레이션이 대량으로 변경됐는지 요약 파일 수준에서 확인
• Summarizer 상태와 요약 파일 내용이 일치하는지 디버깅
• 요약 파일 손상 의심 시 확인

pg_walsummary $PGDATA/pg_wal/summaries/<파일명>

출력은 릴레이션 파일 노드와 변경 블록 범위 목록입니다. 상세 형식은 PostgreSQL 17 공식 문서의 pg_walsummary 항목을 참고하세요.

트레이드오프

얻는 것

• 백업 윈도우 단축: 변경된 블록만 전송하니, 변경률이 낮은 대형 DB에서 백업 시간과 전송량이 눈에 띄게 줄어듭니다.
• 외부 도구 없이 완결: pg_basebackup + pg_combinebackup만으로 체인 백업이 가능합니다. 컨테이너 이미지 하나에 얹기 쉬워졌습니다.
• 무결성 검증 내장: backup_manifest 체크섬으로 파일 손상이 병합 시점에 감지됩니다.

감수해야 하는 것

WAL Summarizer 상시 오버헤드. summarize_wal = on을 켜두면 WAL을 상시 파싱하는 프로세스가 돌고, pg_wal/summaries/ 아래 요약 파일이 지속적으로 쌓입니다. CPU 오버헤드가 크지는 않다고 알려져 있지만 0은 아니고, 요약 파일은 별도 관리 대상이 됩니다. wal_summary_keep_time으로 보존 기간을 조절할 수 있지만, 너무 짧게 잡으면 오래된 백업 기반의 증분이 실패할 수 있습니다.

체인 관리 리스크. 전체 백업부터 모든 중간 증분까지 체인이 완전해야 복구가 성립합니다. 중간 증분 하나가 유실되면 그 이후 체인 전체가 무효화됩니다.

병합 리소스. pg_combinebackup은 체인의 모든 파일이 같은 로컬 파일시스템에 있어야 하고, 병합 결과를 담을 추가 공간과 I/O가 필요합니다. 오브젝트 스토리지에 백업을 두고 있다면 병합 전에 로컬로 내려받아야 합니다.

병렬 전송 한계. pg_basebackup은 여전히 단일 스트림 전송이 기본입니다. 증분 백업 모드에서 블록 단위 병렬 전송은 지원하지 않으며, 이는 자체 워커로 분산 전송을 지원하는 pgBackRest·WAL-G와 차이가 납니다. (참고로 테이블스페이스 단위 병렬화를 위한 -j 옵션은 원래 pg_basebackup에 없고, 이는 pg_dump 계열의 옵션이니 혼동하지 마세요.)

보존/자동화 미탑재. "N일 지난 백업 자동 삭제", "체인 유효성 정기 검증" 같은 기능은 내장되어 있지 않습니다. 스크립트로 직접 짜야 합니다.

도구별 비교

2026년 기준, 주요 후보의 개략적인 포지션은 아래와 같습니다.

각 도구의 최신 지원 범위·라이선스·유지보수 상태는 프로젝트 공식 저장소에서 직접 확인하세요.

언제 쓰고 언제 쓰지 말 것인가

리뷰어 관점에서 정리하면 이렇게 갈립니다.

쓸 만한 상황

• 단일~소수 인스턴스, 일일 변경률이 낮은 OLTP DB
• 외부 도구 도입 부담이 큰 조직(감사·보안 심사 등)
• Kubernetes 오퍼레이터, 자체 백업 컨트롤러 등 PostgreSQL 표준 도구만으로 조합하고 싶은 환경
• 이미 스크립트 기반 백업 오케스트레이션을 갖고 있어, 도구 하나만 갈아 끼우고 싶은 팀

아직은 참는 게 나은 상황

• 수십 개 이상 인스턴스를 중앙에서 관리해야 하는 환경 — 보존 정책과 카탈로그 관리 부재가 결정적입니다
• 일일 변경률이 대략 절반을 넘어가는 워크로드 — 증분의 이점이 사라지고 체인 관리 비용만 남습니다
• 오브젝트 스토리지(S3, GCS 등)에 직접 백업을 쌓아야 하는 파이프라인 — 네이티브로는 로컬 파일시스템만 지원합니다
• 병렬 전송 대역폭이 백업 SLA를 좌우하는 초대형 DB

증분 백업 도입을 검토 중이라면, 먼저 pg_get_wal_summarizer_state()로 Summarizer가 WAL을 무리 없이 따라오는지 확인하고, 스테이징에서 실제 크기의 데이터로 병합·복구를 끝까지 돌려보는 것이 유일하게 신뢰할 수 있는 근거입니다. 벤더의 벤치마크 수치가 아니라 자기 환경의 병합 시간이 도입 여부를 결정합니다.

참고 자료

• PostgreSQL 17 공식 문서 — pg_basebackup
• PostgreSQL 17 공식 문서 — pg_combinebackup
• PostgreSQL 17 공식 문서 — pg_walsummary
• PostgreSQL 17 공식 문서 — Backup and Restore
• PostgreSQL 17 공식 문서 — WAL Configuration (summarize_wal, wal_summary_keep_time)
• PostgreSQL 17 공식 문서 — Recovery Configuration
• Why PostgreSQL 17's Incremental Backup Feature is a Game-Changer — EDB
• Incremental Backup Challenges and Solutions for PostgreSQL 17 — EDB
• Waiting for Postgres 17: Incremental base backups — pganalyze
• PostgreSQL 17: Incremental Backup — Mydbops