PostgreSQL 백업의 시작 - pg_dump 논리 백업 완벽 정리 (Oracle exp/imp 대응, 그림 4개)
테스트 환경: PostgreSQL 17, Rocky Linux 9 / Oracle 19c
DBA에게 백업은 마지막 보루입니다. 다른 건 다 실패해도 백업만 있으면 살아남죠. 반대로 백업이 없으면? 상상하기도 싫습니다.
Oracle에서는 exp/imp, Data Pump, RMAN으로 백업했습니다. PostgreSQL은 크게 논리 백업(pg_dump) 과 물리 백업(pg_basebackup) 두 가지로 나뉩니다. 이번 편은 그 첫 번째, 논리 백업입니다.
이번 편은 운영 시리즈의 네 번째 글이자, 본인이 요청하신 백업/복구 편의 시작입니다. Oracle의 exp/imp에 해당하는 pg_dump를 실전 위주로 다룹니다. 그림 4개와 함께요.
- 논리 백업 vs 물리 백업 (개념 정리)
- pg_dump 4가지 포맷 (뭘 쓸까?)
- 실전 백업/복원 명령어
- 언제 논리 백업을 쓸까
- 자주 하는 실수
논리 백업 vs 물리 백업, 뭐가 달라요?
먼저 큰 그림입니다. PostgreSQL 백업은 두 종류가 있고, 성격이 완전히 다릅니다.
핵심 차이는 이겁니다.
논리 백업 (pg_dump): "데이터를 SQL로 뽑아냄"
→ CREATE TABLE, COPY 같은 SQL 문으로 저장
→ 버전/OS 달라도 복원 가능 (이식성 최고)
→ 테이블 하나만 골라 복원 가능
물리 백업 (pg_basebackup): "데이터 파일을 통째로 복사"
→ 디스크의 실제 파일을 복사
→ 대용량 빠름, PITR/증분 가능
→ 같은 버전/OS만 복원 (14편에서!)
Oracle과 비교하면:
논리 백업 ↔ exp/imp, Data Pump (expdp/impdp)
물리 백업 ↔ RMAN
Oracle DBA라면 "논리=Data Pump, 물리=RMAN"으로 생각하면 딱 맞습니다.
중요: pg_dump는 실행 중에도 다른 사용자를 막지 않습니다. 읽는 동안 특정 시점의 일관된 스냅샷을 뜨기 때문에, 서비스 중에도 백업할 수 있습니다.
★ pg_dump 4가지 포맷 (뭘 쓸까?)
pg_dump에는 4가지 출력 포맷이 있습니다. 이걸 잘 고르는 게 중요합니다.
custom (-Fc) ← 대부분 이거!
pg_dump -Fc mydb > mydb.dump
압축된 바이너리 파일입니다. 운영 백업의 표준입니다.
- 자동 압축
- 선택적 복원 (특정 테이블만)
- 병렬 복원 가능
- pg_restore로 복원
고민되면 그냥 custom 쓰세요.
directory (-Fd) ← 대용량엔 이게 최고
pg_dump -Fd -j 4 mydb -f mydb_dir
폴더에 여러 파일로 저장합니다. 병렬 덤프(-j) 가 가능해서 대용량 DB에서 가장 빠릅니다.
plain (-Fp) ← 기본값, SQL 텍스트
pg_dump mydb > mydb.sql
순수 SQL 파일입니다. 사람이 읽기 쉽지만, 선택/병렬 복원이 안 됩니다. psql로 복원합니다.
tar (-Ft)
tar 아카이브 형식인데, custom이 상위 호환이라 거의 안 씁니다.
정리:
일반 운영 백업 → custom (-Fc)
대용량 DB → directory (-Fd -j)
간단히 SQL로 보고 싶을 때 → plain
★ 실전 백업/복원 흐름
이제 실제로 해봅시다. custom 포맷 기준입니다.
1단계: 백업
# 기본 백업 (custom 포맷)
pg_dump -U postgres -Fc mydb > mydb.dump
# 압축 레벨 지정 + 진행 상황 표시
pg_dump -U postgres -Fc -Z 6 -v mydb > mydb.dump
# 대용량은 directory + 병렬
pg_dump -U postgres -Fd -j 4 mydb -f mydb_backup
2단계: 검증 (반드시!)
# 백업 파일 내용 목록 확인
pg_restore --list mydb.dump
이 명령으로 백업이 제대로 됐는지, 어떤 객체가 들어있는지 확인합니다.
3단계: 복원
# 새 DB 만들고 복원
createdb newdb
pg_restore -U postgres -d newdb mydb.dump
# 병렬 복원 (빠름)
pg_restore -U postgres -d newdb -j 4 mydb.dump
# 특정 테이블만 복원 (custom 포맷의 강점!)
pg_restore -U postgres -d newdb -t employees mydb.dump
plain 포맷은 psql로
# plain(-Fp)으로 뜬 건 psql로 복원
psql -U postgres -d newdb < mydb.sql
★ 가장 중요한 원칙: 복원 테스트
여기가 이 글에서 제일 중요한 부분입니다.
"복원해보지 않은 백업은 백업이 아니다"
백업 파일이 있다고 안심하면 안 됩니다. 실제로 복원이 되는지 정기적으로 테스트해야 합니다. 백업은 잘 됐는데 막상 복원하려니 안 되는 경우가 실무에서 정말 많습니다. 그때는 이미 늦습니다.
# 정기 복원 테스트 (테스트 서버에서)
createdb test_restore
pg_restore -d test_restore mydb.dump
# 데이터 건수 확인 등으로 검증
psql -d test_restore -c "SELECT count(*) FROM employees;"
dropdb test_restore
이걸 자동화 스크립트로 만들어 주기적으로 돌리는 걸 강력히 권합니다.
전체 클러스터 백업 - pg_dumpall
pg_dump는 DB 하나만 백업합니다. 롤(사용자), 테이블스페이스 같은 전역 객체나 모든 DB를 백업하려면 pg_dumpall을 씁니다.
# 전체 클러스터 백업 (모든 DB + 롤 + 테이블스페이스)
pg_dumpall -U postgres > full_cluster.sql
# 전역 객체만 (롤, 테이블스페이스)
pg_dumpall -U postgres --globals-only > globals.sql
실무 팁: 보통 이렇게 조합합니다.
pg_dumpall --globals-only → 롤/권한 백업 (9편 참고)
pg_dump -Fc 각 DB → 개별 DB 백업 (선택 복원 위해)
pg_dumpall은 plain 포맷만 지원해서, 개별 DB는 pg_dump custom으로 따로 뜨는 게 유연합니다.
★ 언제 논리 백업을 쓸까?
논리 백업이 만능은 아닙니다. 빛나는 상황이 따로 있습니다.
논리 백업이 좋은 경우:
O 버전 업그레이드 마이그레이션 (14→17 등)
O 다른 서버/클라우드로 이전
O 특정 테이블만 백업/복원
O 개발/테스트용 데이터 복사
O 중소 규모 DB (수십 GB 이하)
논리 백업의 최대 강점은 유연함입니다. PostgreSQL 14에서 뜬 백업을 17에 복원할 수 있고, 리눅스에서 뜬 걸 다른 OS에 복원할 수도 있습니다. 이 이식성은 물리 백업이 못 하는 겁니다.
물리 백업이 나은 경우 (14편):
O 대용량 운영 DB (수백 GB 이상)
O 정기 자동 백업
O 특정 시점 복구(PITR) 필요
O 증분 백업으로 공간 절약
핵심: 공식 문서도 "정기적인 운영 백업엔 pg_dump가 최선이 아닐 수 있다"고 안내합니다. 대용량 운영 DB의 정기 백업은 다음 편의 물리 백업이 담당합니다. pg_dump는 마이그레이션과 선택적 백업에 강합니다.
대용량에서 주의할 점: 인덱스 재구축
논리 백업의 함정 하나를 짚고 갑니다.
논리 백업은 인덱스 "데이터"를 저장하지 않습니다.
대신 CREATE INDEX 문을 저장합니다.
→ 복원 시 모든 인덱스를 처음부터 다시 만듭니다!
작은 DB는 상관없지만, 1000만 행에 인덱스 5개짜리 테이블이라면 이 인덱스 재구축이 복원 시간의 대부분을 차지합니다. 대용량 DB에서 논리 백업 복원이 느린 주된 이유입니다.
이것도 대용량엔 물리 백업(14편)이 유리한 이유 중 하나입니다.
★ AI로 백업 전략 세우기
백업 전략이 고민되면 Claude에게 물어보세요.
프롬프트:
"PostgreSQL 17 백업 전략을 설계해줘.
- DB 크기: [예: 50GB]
- 요구사항: [일 1회 백업, 30일 보관 등]
- 용도: [운영/마이그레이션 등]
논리 백업(pg_dump)과 물리 백업 중 무엇이 맞을지,
구체적 명령어와 자동화 스크립트, 검증 방법까지
Oracle DBA가 이해하기 쉽게 알려줘."
⚠️ 검증 필수: 백업 스크립트는 반드시 테스트 환경에서 복원까지 확인하세요. 백업만 되고 복원이 안 되면 의미가 없습니다.
자주 하는 실수 TOP 5
1. 복원 테스트 안 함
백업만 믿고 복원 테스트를 안 함. 정작 필요할 때 복원 실패. 정기 복원 테스트 필수.
2. plain 포맷으로 대용량 백업
plain은 선택/병렬 복원이 안 됨. 운영은 custom(-Fc)으로.
3. 롤/권한 백업 누락
pg_dump는 DB만 백업. 롤은 pg_dumpall --globals-only로 따로.
4. 대용량에 논리 백업 고집
수백 GB인데 pg_dump 쓰다 복원에 몇 시간. 대용량은 물리 백업(14편).
5. 백업 파일 방치
백업을 같은 서버에만 저장. 서버가 죽으면 백업도 같이 죽음. 오프사이트(다른 위치) 보관 필수.
마무리
pg_dump 논리 백업의 핵심입니다.
- 논리 백업 = SQL로 추출 — 이식성 최고
- custom(-Fc) 포맷 — 운영 백업 표준
- 대용량은 directory + 병렬(-j)
- 복원 테스트가 진짜 백업 — 정기적으로!
- 마이그레이션/선택 복원에 강함 — 대용량 정기 백업은 물리 백업
논리 백업은 Oracle의 Data Pump처럼 유연하고 이식성 좋은 백업입니다. 버전 업그레이드나 서버 이전에는 이만한 게 없습니다. 다만 "복원해보지 않은 백업은 백업이 아니다"라는 원칙만은 꼭 기억하세요. 15년 운영하며 가장 뼈저리게 배운 교훈입니다.
다음 편에서는 물리 백업과 PITR를 다룹니다. pg_basebackup, WAL 아카이빙, 그리고 본인이 요청하신 증분 백업까지. Oracle의 RMAN에 해당하는, 대용량 운영 DB의 진짜 백업입니다.
여러분의 백업 전략이나 아찔했던 복구 경험이 있다면 댓글로 공유해주세요. 다른 DBA들에게 큰 교훈이 됩니다.