PostgreSQL 물리 백업 & PITR 완벽 정리 - 증분 백업까지 (Oracle RMAN 대응)
테스트 환경: PostgreSQL 17, Rocky Linux 9 / Oracle 19c
"실수로 운영 테이블을 DROP 했어요. 오후 3시였는데, 2시 59분으로 되돌릴 수 있나요?"
Oracle DBA라면 "RMAN으로 PITR 하면 되지"라고 답할 겁니다. PostgreSQL도 됩니다. 바로 이번 편의 주제, 물리 백업과 PITR(시점 복구) 입니다.
13편의 논리 백업(pg_dump)이 "유연한 백업"이었다면, 이번 물리 백업은 "대용량 운영 DB의 진짜 백업" 입니다. 그리고 본인이 요청하신 증분 백업도 드디어 나옵니다. 마침 PostgreSQL 17에서 증분 백업이 새로 추가돼서 시의적절해요.
이번 편은 운영 시리즈의 다섯 번째 글이자, 백업/복구 편의 완결입니다. 그림 5개로 확실히 정리합니다.
- 물리 백업 3대 무기 (pg_basebackup, WAL, PITR)
- PITR - 사고 직전으로 되돌리기
- ★ 증분 백업 (PostgreSQL 17 신기능)
- 실전 명령어 흐름
- 백업 전략 완성 (논리+물리 조합)
물리 백업 3대 무기 (= Oracle RMAN)
먼저 큰 그림입니다. PostgreSQL 물리 백업은 세 가지가 함께 작동합니다.
pg_basebackup: 데이터 파일 통째로 복사 (전체/증분)
→ Oracle RMAN 백업에 해당
WAL 아카이빙: 트랜잭션 로그(변경분)를 계속 보관
→ Oracle Archive Log에 해당
PITR: 전체 백업 + WAL 재생 = 특정 시점으로 복구
→ Oracle RMAN PITR에 해당
핵심 공식을 기억하세요.
전체 백업(base) + WAL 재생 = 원하는 시점으로 복구
이 세 개가 어떻게 맞물리는지가 이번 편의 전부입니다.
전체 백업 뜨기 - pg_basebackup
가장 기본인 전체 백업입니다.
# 전체 물리 백업
pg_basebackup -D /backup/full -Ft -z -P -c fast
# 옵션 설명
# -D: 백업 저장 위치
# -Ft: tar 포맷
# -z: 압축
# -P: 진행 상황 표시
# -c fast: 즉시 체크포인트
사전 준비가 필요합니다.
1. REPLICATION 권한이 있는 유저 (또는 슈퍼유저)
2. postgresql.conf: max_wal_senders 충분히 (기본 10, OK)
3. pg_hba.conf: replication 연결 허용
pg_basebackup은 서비스 중에도 백업할 수 있습니다. 다른 클라이언트를 막지 않아요.
★ PITR - 사고 직전으로 되돌리기
물리 백업의 진짜 위력은 PITR입니다. "특정 시점"으로 정확히 되돌릴 수 있어요.
시나리오
새벽 2시: 전체 백업 완료
그 후: WAL(트랜잭션 로그)이 계속 쌓임
오후 3시: 누군가 실수로 DROP TABLE!
→ 목표: 2시 59분 59초(사고 1초 전)로 복구
원리
1. 새벽 2시 전체 백업을 복원
2. WAL을 "오후 2:59:59까지만" 재생
3. → 사고가 없던 상태로 돌아감!
WAL 아카이빙 설정
PITR을 하려면 WAL을 보관해야 합니다.
# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'cp %p /archive/%f' # WAL을 아카이브로 복사
복구 설정
# 복구 시 (PostgreSQL 12+는 postgresql.conf에)
restore_command = 'cp /archive/%f %p'
recovery_target_time = '2026-07-01 14:59:59' # 이 시점까지
이렇게 하면 지정한 시점까지 WAL을 재생하고 멈춥니다. Oracle의 UNTIL TIME과 같은 개념이에요.
★ 증분 백업 (PostgreSQL 17 신기능!)
드디어 증분 백업입니다. PostgreSQL 17에서 새로 추가된 기능이라 특히 주목할 만해요.
왜 증분인가
매일 전체 백업하면:
일 100GB × 7일 = 700GB (공간 낭비!)
전체 + 증분이면:
일요일 전체 100GB
+ 월~토 증분 각 2~3GB
= 약 115GB (85% 절약!)
증분 백업은 직전 백업 이후 변경된 블록만 저장합니다. 그래서 훨씬 작고 빠릅니다.
전제조건 (딱 하나!)
-- WAL 요약 기능 켜기 (증분 백업의 필수 조건)
ALTER SYSTEM SET summarize_wal = on;
SELECT pg_reload_conf();
-- 확인
SHOW summarize_wal; -- on 이어야 함
이걸 안 켜면 증분 백업이 안 됩니다. 꼭 먼저 켜세요.
★ 증분 백업 복원 주의점
여기가 함정입니다.
증분 백업은 "직접 복원 불가"!
→ pg_combinebackup으로 전체+증분을 합쳐야 함
증분 파일만으로는 복원할 수 없어요. 반드시 전체 백업과 결합해야 완전한 DB가 됩니다.
★ 증분 백업 실전 흐름
실제 명령어로 처음부터 끝까지 해봅시다.
# 0. 사전: summarize_wal = on (위에서 설정)
# 1. 전체 백업 (기준점)
pg_basebackup -D /backup/full -c fast
# 2. 증분 백업 (전체의 manifest를 기준으로)
pg_basebackup -D /backup/incr \
--incremental=/backup/full/backup_manifest
# 3. 복원: 전체 + 증분을 결합 (오래된 것부터 순서대로!)
pg_combinebackup /backup/full /backup/incr -o /restored
# 4. 결합된 /restored 디렉토리로 DB 기동
pg_combinebackup 순서 주의: 반드시 오래된 것부터 나열합니다. 전체 백업 먼저, 그다음 증분 순서대로. 순서가 틀리면 복원이 안 됩니다.
PITR vs 증분 백업, 뭐가 다를까
둘 다 "특정 시점 복구"를 하지만 방식이 달라요.
PITR: WAL을 재생 (중간 상태를 다 거침)
→ 한 행이 100번 바뀌었으면 100번의 변경을 다 재생
→ 정밀하지만 느리고 WAL 공간 많이 씀
증분 백업: 최종 상태만 저장
→ 100번 바뀌어도 최종 결과 1개만
→ 더 작고 빠름, 대신 백업 시점으로만 복구
실무에서는 증분 백업(정기) + WAL 아카이빙(정밀 PITR) 을 함께 씁니다.
백업 전략 완성 - 논리 + 물리 조합
이제 13편(논리)과 14편(물리)을 어떻게 조합할지 정리합니다.
일상 운영 백업 (물리)
주간: pg_basebackup 전체 백업
일간: --incremental 증분 백업
상시: WAL 아카이빙 (PITR 대비)
→ 대용량 운영 DB의 표준
특수 목적 백업 (논리, 13편)
마이그레이션: pg_dump (버전 업그레이드 등)
특정 테이블: pg_dump -t
롤/권한: pg_dumpall --globals-only
→ 유연함이 필요할 때
★ 3-2-1 백업 원칙
백업의 황금률입니다. 꼭 기억하세요.
3개의 복사본
2개의 다른 매체 (디스크 + 클라우드 등)
1개는 오프사이트 (다른 물리적 위치)
그리고 13편에서 강조한 "복원 테스트" 는 물리 백업에도 그대로 적용됩니다. 정기적으로 실제 복원해보세요.
Oracle DBA를 위한 매핑 정리
Oracle 경험을 PostgreSQL로 옮기는 매핑입니다.
Oracle PostgreSQL
─────────────────────────────────────────────
RMAN 전체 백업 → pg_basebackup
RMAN 증분 백업 → pg_basebackup --incremental
Archive Log → WAL 아카이빙
RMAN PITR (UNTIL TIME) → recovery_target_time
RMAN CATALOG → backup_manifest
Data Guard → 스트리밍 복제 (15편에서!)
개념은 거의 1:1로 대응됩니다. Oracle에서 RMAN을 다뤄봤다면 PostgreSQL 물리 백업도 금방 익숙해집니다.
★ AI로 백업 자동화 스크립트 만들기
백업 자동화가 필요하면 Claude에게 맡겨보세요.
프롬프트:
"PostgreSQL 17 백업 자동화 스크립트를 만들어줘.
- 주간 전체 백업 + 일간 증분 백업
- WAL 아카이빙 설정
- 30일 이상 된 백업 자동 삭제
- 백업 성공/실패 알림
- 복원 테스트 스크립트도 별도로
cron 설정과 함께, Oracle DBA가 이해하기 쉽게
주석 달아서 만들어줘."
⚠️ 검증 필수: 백업 스크립트는 반드시 테스트 환경에서 전체 사이클(백업→결합→복원) 을 확인하세요. 특히 증분 백업은 pg_combinebackup 순서, PITR은 recovery_target 설정을 실제로 테스트해야 합니다. 백업은 "복원될 때"만 의미가 있습니다.
자주 하는 실수 TOP 5
1. summarize_wal 안 켬
증분 백업하려는데 안 됨. ALTER SYSTEM SET summarize_wal = on 먼저.
2. WAL 아카이브 공간 부족
WAL이 계속 쌓이는데 정리 안 함 → 디스크 부족(12편). 보관 정책 필수.
3. pg_combinebackup 순서 오류
증분을 전체보다 먼저 나열 → 복원 실패. 오래된 것부터!
4. 백업만 하고 복원 테스트 안 함
13편에서도 강조한 그 실수. 물리 백업도 정기 복원 테스트 필수.
5. 백업을 같은 서버에만
서버가 죽으면 백업도 같이 죽음. 3-2-1 원칙으로 오프사이트 보관.
마무리
PostgreSQL 물리 백업과 PITR의 핵심입니다.
- pg_basebackup — 대용량 운영 DB의 전체 백업 (= RMAN)
- WAL 아카이빙 + PITR — 사고 직전 시점으로 복구
- 증분 백업 (PG17) — 변경분만, 공간 85% 절약 (summarize_wal 필수)
- pg_combinebackup — 증분 복원은 전체+증분 결합
- 논리+물리 조합 + 3-2-1 — 완벽한 백업 전략
이걸로 본인이 요청하신 백업/복구 Full/증분을 두 편(13~14편)에 걸쳐 모두 다뤘습니다. 논리 백업의 유연함과 물리 백업의 속도·복구력을 조합하면, Oracle RMAN 못지않은 백업 체계를 만들 수 있습니다.
가장 중요한 건 역시 "복원해보지 않은 백업은 백업이 아니다" 입니다. 15년 운영하며 가장 뼈저리게 배운 이 교훈, PostgreSQL에서도 변하지 않습니다.
여러분의 백업 전략이나 PITR로 사고를 막은 경험이 있다면 댓글로 공유해주세요.