신뢰할 수 있는 PostgreSQL 백업을 위한 꼭 알아야 할 pg_dump 옵션 Top 10
Source: Dev.to
PostgreSQL의 pg_dump 유틸리티는 논리 백업을 만들기 위한 대표적인 도구이지만, 실제 힘은 백업 대상과 방식을 정확히 지정할 수 있는 수십 가지 명령줄 옵션에 있습니다. 어떤 옵션을 언제 사용해야 하는지를 알면, 위기 상황에서 프로젝트를 구해낼 수 있는 백업과 그렇지 못한 백업을 가르는 차이가 됩니다. 이 가이드는 모든 개발자와 DBA가 반드시 숙지해야 할 핵심 pg_dump 옵션을 다룹니다.
1. -F / --format 로 포맷 선택
포맷 옵션은 백업이 어떻게 저장되는지와 복구 시 어떤 기능을 사용할 수 있는지를 결정합니다. 올바른 포맷을 처음부터 선택하면 복구 시 시간과 복잡성을 크게 줄일 수 있습니다. 이 하나의 옵션이 압축, 병렬 복원 지원 및 파일 호환성에 영향을 미칩니다.
| 포맷 | 플래그 | 확장자 | 압축 | 병렬 복원 | 가장 적합한 경우 |
|---|---|---|---|---|---|
| Plain | -F p | .sql | 없음 | 없음 | 작은 DB, 수동 검토 필요 시 |
| Custom | -F c | .dump | 있음 | 있음 | 대부분의 운영 환경 |
| Directory | -F d | 폴더 | 있음 | 있음 | 매우 큰 데이터베이스 |
| Tar | -F t | .tar | 없음 | 없음 | 아카이브 호환성 필요 시 |
# Custom 포맷 (대부분의 경우 권장)
pg_dump -F c -d myapp -f backup.dump
# 병렬 작업을 위한 Directory 포맷
pg_dump -F d -d myapp -f backup_dir/용량이 500 GB 이하인 데이터베이스는 커스텀 포맷(-F c)이 압축, 유연성, 복원 속도 측면에서 가장 좋은 균형을 제공합니다.
2. -j / --jobs 로 병렬 덤프
jobs 옵션은 동시에 실행할 프로세스 수를 지정해 병렬 덤프를 가능하게 합니다. 이 옵션은 디렉터리 포맷(-F d)에서만 동작하며, 여러 테이블을 동시에 덤프함으로써 대용량 데이터베이스의 백업 시간을 크게 단축합니다.
# 4개의 병렬 프로세스로 덤프
pg_dump -F d -j 4 -d myapp -f backup_dir/일반적인 원칙은 CPU 코어 수와 맞추되, 데이터베이스 서버를 위해 최소 하나의 코어는 남겨두는 것입니다. 예를 들어 8코어 서버라면 -j 6 혹은 -j 7 정도가 다른 프로세스를 방해하지 않으면서 최적의 성능을 제공합니다.
3. -t / --table 로 테이블 선택
전체 데이터베이스가 아니라 특정 테이블만 백업합니다. 플래그를 여러 번 반복하거나 와일드카드를 사용해 패턴 매칭도 가능합니다.
# 단일 테이블 백업
pg_dump -d myapp -t users -f users_backup.sql
# 여러 테이블 백업
pg_dump -d myapp -t users -t orders -t products -f critical_tables.sql
# 패턴 매칭을 위한 와일드카드 사용
pg_dump -d myapp -t 'public.user_*' -f user_tables.sql테이블 이름은 대소문자를 구분하며, public이 아닌 스키마를 사용할 경우 스키마 접두사를 포함해야 합니다(예: -t sales.orders).
4. -T / --exclude-table 로 테이블 제외
특정 테이블(또는 패턴)을 덤프에서 제외합니다. 크기가 큰 로그, 세션, 임시 테이블 등을 건너뛰고 싶을 때 유용합니다.
# 로그와 세션 테이블 제외
pg_dump -d myapp -T logs -T sessions -T temp_data -f backup.sql
# 패턴에 맞는 테이블 제외
pg_dump -d myapp -T 'public.*_log' -T 'public.*_temp' -f backup.sql-T 옵션을 정기 백업에 결합하면, 대용량 감사 또는 로깅 테이블이 포함된 경우 백업 크기를 50 % 이상 줄일 수 있습니다.
5. --schema-only 로 스키마만 백업
데이터 없이 데이터베이스 구조(테이블, 인덱스, 제약조건, 함수, 트리거)만 내보냅니다. 버전 관리, 문서화, 빈 복제본 생성 등에 이상적입니다.
# 전체 스키마 내보내기
pg_dump -d myapp --schema-only -f schema.sql
# 특정 테이블만 스키마 백업
pg_dump -d myapp --schema-only -t users -t orders -f tables_schema.sql스키마 전용 백업은 데이터베이스 크기에 관계없이 보통 수백 킬로바이트 수준이므로, 애플리케이션 코드와 함께 Git 저장소에 보관하기에 적합합니다.
6. --data-only 로 데이터만 백업
스키마 정의를 제외하고 행 데이터만 내보냅니다. 기존 스키마가 이미 구축된 데이터베이스에 데이터를 새로 채우거나 테스트용 데이터 스냅샷을 만들 때 유용합니다.
# 스키마 없이 모든 데이터 내보내기
pg_dump -d myapp --data-only -f data.sql
# INSERT 구문을 사용한 데이터 전용 백업(이식성 높음)
pg_dump -d myapp --data-only --inserts -f data_inserts.sql--data-only 를 사용할 경우 대상 데이터베이스에 테이블, 제약조건, 시퀀스 등 정확한 스키마가 미리 존재해야 합니다.
7. -Z / --compress 로 압축 레벨 지정
커스텀 및 디렉터리 포맷에서 압축 수준을 제어합니다(0 = 압축 없음, 9 = 최대 압축). 높은 레벨은 파일을 더 작게 만들지만 생성 시간이 길어집니다.
| 레벨 | 속도 | 크기 감소 | 가장 적합한 경우 |
|---|---|---|---|
| 0 | 가장 빠름 | 없음 | 테스트, 빠른 복구가 우선인 경우 |
| 1‑3 | 빠름 | 보통 | 일일 백업, 균형 잡힌 접근 |
| 4‑6 | 중간 | 좋음 | 일반 운영 환경 백업 |
| 7‑9 | 느림 | 최대 | 장기 보관, 저장 공간 제한 상황 |
# 보관용 최대 압축
pg_dump -F c -Z 9 -d myapp -f backup.dump
# 빈번한 백업을 위한 빠른 압축
pg_dump -F c -Z 1 -d myapp -f backup.dump대부분의 운영 환경에서는 기본값인 -Z 6 이 압축 효율과 속도 사이의 최적 비율을 제공합니다.
8. -c / --clean 로 객체 정리
덤프에 DROP 구문을 CREATE 구문 앞에 추가해 복원 시 기존 객체를 삭제하고 새로 만들게 합니다. --if-exists 와 함께 사용하면 객체가 없을 때 발생하는 오류를 방지할 수 있습니다.
# DROP 구문 포함 백업
pg_dump -d myapp -c -f backup.sql
# 객체가 없을 경우 오류 방지를 위해 --if-exists와 결합
pg_dump -d myapp -c --if-exists -f backup.sql9. -C / --create 로 데이터베이스 생성 포함
CREATE DATABASE 구문과 연결 명령을 포함시켜 백업을 완전하게 독립된 형태로 만듭니다. 복원 시 대상 데이터베이스가 아니라 유지 관리용 데이터베이스(예: postgres)에 먼저 연결해야 합니다.
# CREATE DATABASE 구문 포함
pg_dump -d myapp -C -f backup.sql
# clean과 create를 모두 포함한 전체 백업
pg_dump -d myapp -C -c --if-exists -f backup.sql