postgres db 백업 정리: pg_dump와 PITR 선택 기준

postgres db 백업은 결국 두 갈래로 정리됩니다. 스키마와 데이터를 파일로 뽑아내는 논리 백업과, 데이터 디렉터리와 WAL을 그대로 복사하는 물리 백업이에요. 운영 중인 클러스터라면 물리 백업과 WAL 아카이빙을 기본으로 두고, 이전과 부분 복구를 위한 논리 백업을 함께 잡는 구성이 가장 안전해요.

한눈에 보기

논리 백업은 pg_dump로 뜨고, 특정 데이터베이스나 특정 테이블만 골라 복원할 때 유리해요.
물리 백업은 pg_basebackup으로 뜨고, 클러스터 전체를 그대로 되살릴 때 유리해요.
특정 시점 복구는 베이스 백업과 WAL 아카이브를 함께 보관해야 성립해요. WAL만 있어서는 되돌릴 시작점이 없어요.
백업은 "만들었다"보다 "복원 리허설을 통과했다"가 중요해요. 파일 목록 확인과 실제 복원을 한 번씩 해 두세요.
백업 파일과 WAL 아카이브는 원본 서버와 다른 위치에 두는 것이 기본이에요.

백업 방식 비교

방식	복사 대상	강점	주의할 점
`pg_dump` (아카이브 형식)	한 데이터베이스의 스키마와 데이터	부분 복원, 다른 주 버전으로 이전, 선택적 객체 복원	덤프 시점 하나만 복원 가능하고 대용량에서는 오래 걸려요
`pg_dump -Fd` (디렉터리 형식)	같은 대상, 파일을 나누어 저장	병렬 덤프와 병렬 복원으로 시간을 줄여요	디렉터리 전체를 함께 보관해야 해요
`pg_dumpall`	클러스터의 모든 데이터베이스와 전역 객체	롤과 권한까지 한 번에 넘길 수 있어요	복원이 단일 스트림으로 흘러가요
`pg_basebackup`	데이터 디렉터리 전체	클러스터 통째로 복구, PITR의 시작점	같은 주 버전과 같은 아키텍처에서만 복원돼요
WAL 아카이빙	커밋된 변경 기록	베이스 백업 이후 임의 시점으로 복구	아카이브 실패를 감시하지 않으면 조용히 끊겨요
파일 시스템 스냅샷	볼륨 단위	뜨는 속도가 빠르고 부하가 작아요	일관성은 별도 절차로 보장해야 해요

표에서 보듯 두 축은 "무엇을 복원하고 싶은가"와 "어느 시점으로 돌아가고 싶은가"로 갈립니다.

pg_dump로 논리 백업하기

pg_dump는 서버에 접속해 하나의 일관된 스냅샷을 읽고, 그 내용을 SQL 또는 아카이브 파일로 써 냅니다. 덤프가 도는 동안 다른 트랜잭션이 커밋되어도 결과에는 섞이지 않아요.

첫 단계는 대상과 접속 정보를 확정하는 일이에요. 호스트, 포트, 사용자, 데이터베이스 이름을 정하고, 비밀번호는 .pgpass나 서비스 파일로 관리해 명령행 기록에 남기지 않는 편이 좋아요.

pg_dump -h db.internal -U app_ro -d appdb -Fc -f /backup/appdb.dump

형식은 세 가지를 기억하면 충분해요. -Fc는 압축된 사용자 정의 형식으로 pg_restore에서 객체를 골라 복원할 수 있어요. -Fd는 디렉터리에 파일을 나눠 담아 -j 옵션으로 병렬 처리할 수 있어요. 아무것도 지정하지 않으면 평문 SQL 스크립트가 나오는데, 사람이 읽고 diff로 비교하기에는 편하지만 부분 복원은 어려워요.

병렬 덤프는 디렉터리 형식에서만 동작해요.

pg_dump -Fd -j "$(nproc)" -f /backup/appdb_dir appdb

스키마만 필요할 때는 -s, 데이터만 필요할 때는 -a, 특정 테이블만 필요할 때는 -t를 붙여요. 운영 데이터베이스에서 실수로 전체를 긁지 않으려면 이 옵션들을 미리 익혀 두는 것이 좋아요.

복원은 pg_restore로 해요. 빈 데이터베이스를 만들고そこ에 밀어 넣는 흐름이 기본이에요.

createdb -h db.internal -U app_owner appdb_restore
pg_restore -h db.internal -U app_owner -d appdb_restore -j "$(nproc)" /backup/appdb.dump

--clean은 대상 객체를 먼저 지우고 다시 만들기 때문에 운영 데이터베이스에 그대로 쓰면 위험해요. --list로 목차를 먼저 확인하고, 필요하면 목차 파일을 편집해 원하는 객체만 골라 복원하는 방식이 안전합니다.

전역 객체, 그러니까 롤과 권한 같은 요소는 데이터베이스 덤프에 들어가지 않아요. 이 부분은 pg_dumpall --globals-only로 따로 뽑아 두세요.

pg_basebackup으로 물리 백업하기

물리 백업은 데이터 디렉터리를 그대로 복사합니다. 그래서 복원이 빠르고, WAL 아카이빙과 결합하면 특정 시점 복구의 출발점이 돼요.

pg_basebackup -h db.internal -U replicator -D /backup/base -Ft -z -P -X stream

이 명령이 동작하려면 서버 쪽에서 복제 연결을 허용해야 해요. wal_level이 복제를 지원하는 값이어야 하고, max_wal_senders가 넉넉해야 하며, pg_hba.conf에 복제 권한이 열려 있어야 합니다. -X stream은 백업 중에 생성된 WAL까지 함께 받아 두어 백업 자체가 일관된 상태로 끝나게 해 줘요.

복원은 서버를 멈추고 데이터 디렉터리를 교체하는 방식으로 진행해요. 이때 주 버전이 다르면 그대로 뜨지 않으니, 백업을 받은 서버와 같은 주 버전의 바이너리를 준비해야 합니다. 복구 설정 파일의 이름과 형식은 주 버전에 따라 다르므로, 사용 중인 버전의 공식 문서를 확인하는 것이 확실해요.

WAL 아카이빙과 특정 시점 복구

특정 시점 복구는 "베이스 백업 + 그 이후의 WAL"이라는 조합으로 동작해요. 베이스 백업을 뜬 시점부터 원하는 시점까지 WAL을 순서대로 재생하는 구조예요.

서버 설정에서는 wal_level을 복제 가능한 수준으로 두고, archive_mode를 켠 뒤 archive_command로 WAL 세그먼트를 외부 저장소에 복사해요. 이 명령이 실패하면 WAL이 쌓여 디스크를 채우므로, 아카이브 성공 여부를 주기적으로 확인해야 합니다. pg_stat_archiver 뷰를 보면 마지막 성공 시각과 실패 건수를 확인할 수 있어요.

복구할 때는 restore_command로 아카이브에서 WAL을 가져오게 하고, 목표 시점을 지정해 그 지점에서 재생을 멈추게 해요. 실수로 지운 데이터를 되살릴 때는 삭제 직전 시점을 목표로 잡는 식이에요.

이 과정을 직접 스크립트로 관리하는 대신 백업 도구를 쓰는 팀도 많아요. 베이스 백업 스케줄링, WAL 보관, 보존 기간 관리, 무결성 검증을 한곳에서 처리할 수 있기 때문이에요.

상황별 선택

다른 서버로 데이터베이스 하나를 옮길 때는 pg_dump -Fc가 간단해요.
특정 테이블 하나만 되살릴 때는 pg_dump -t로 그 테이블만 뽑는 편이 빠릅니다.
클러스터 전체를 특정 시점으로 되돌려야 한다면 pg_basebackup과 WAL 아카이빙 조합이 필요해요.
데이터가 커서 복원 시간이 문제라면 물리 백업이 유리해요.
스키마 변경을 리뷰하거나 이관 스크립트를 만들 때는 pg_dump -s로 스키마만 뽑아요.
읽기 전용 복제본에서 덤프를 뜨면 주 서버 부하를 줄일 수 있어요.

주의할 점

백업 파일을 원본 서버의 같은 볼륨에 두면 서버 장애와 백업 유실이 동시에 일어납니다. 오브젝트 스토리지나 별도 호스트로 옮기고, 보존 기간과 삭제 정책을 함께 정해 두세요.

pg_dump는 공짜가 아니에요. 읽기 부하가 발생하고, 덤프가 도는 동안 테이블에 공유 잠금이 걸려 DDL이 대기할 수 있어요. 마이그레이션 시간대와 겹치지 않게 스케줄을 잡는 것이 좋습니다.

논리 백업은 덤프 시점 하나만 복원할 수 있어요. "어제 오후의 특정 시각"으로 돌아가야 한다면 논리 백업만으로는 부족하고 WAL 아카이빙이 필요해요.

복원 환경도 미리 점검하세요. 확장 모듈이 설치되어 있지 않거나, 롤과 권한이 없거나, 대상 주 버전이 다르면 복원이 중간에 멈춥니다. 백업 파일만 검사하지 말고 실제 인스턴스에 복원해 보는 리허설을 정기적으로 돌리는 것이 가장 확실한 검증이에요.

자주 묻는 질문

pg_dump는 서비스 중에 실행해도 괜찮나요?

네, pg_dump는 하나의 일관된 스냅샷을 기준으로 읽기 때문에 덤프 도중의 변경이 결과에 섞이지 않아요. 다만 읽기 부하가 발생하고 덤프 대상 테이블에 공유 잠금이 걸려 DDL이 대기할 수 있으니, 트래픽이 적은 시간대나 복제본에서 실행하는 편이 좋아요.

논리 백업과 물리 백업 중 무엇을 먼저 갖춰야 하나요?

운영 클러스터라면 물리 백업과 WAL 아카이빙을 기본으로 두고, 이전과 부분 복구를 위한 논리 백업을 함께 잡는 구성을 권해요. 둘은 대체 관계가 아니라 역할이 달라서, 같은 날짜의 백업이라도 쓰임이 완전히 다릅니다.

백업 파일이 정상인지 어떻게 확인하나요?

pg_restore --list로 목차가 읽히는지 먼저 확인하고, 별도 인스턴스에 실제로 복원해 보는 것이 가장 확실해요. 복원까지 걸리는 시간을 함께 재 두면 장애 상황에서 복구 계획을 세울 때 도움이 됩니다.

WAL 아카이빙만 있으면 복구할 수 있나요?

아니요. WAL은 베이스 백업 위에 얹어 재생하는 재료예요. 기준이 되는 베이스 백업이 없으면 재생을 시작할 지점이 없어서 복구가 성립하지 않습니다.

백업 주기는 어떻게 정하면 되나요?

데이터가 다시 만들어질 수 있는지, 얼마나 오래된 시점까지 되돌릴 필요가 있는지를 기준으로 정해요. 복구 목표 시점과 허용 가능한 데이터 유실 범위를 먼저 합의하고, 그에 맞춰 베이스 백업 주기와 WAL 보관 기간을 정하는 순서가 자연스럽습니다.

출처

백업은 뜨는 절차보다 되돌리는 절차가 본체예요. 함께 보면 좋은 운영 글도 정리해 두었으니, PostgreSQL WAL과 체크포인트 이해하기, pg_restore로 부분 복구하기, 운영 DB 마이그레이션 체크리스트를 이어서 읽어 보시면 복구 리허설까지 자연스럽게 이어집니다.