postgres 백업 정리: pg_dump부터 PITR까지

postgres 백업은 논리 백업과 물리 백업을 목적에 따라 나누고, 복원까지 검증하는 것이 핵심이에요. 일상적인 부분 복구와 이관에는 pg_dump를, 클러스터 전체와 장애 복구에는 pg_basebackup과 WAL 아카이빙을 조합하는 방식이 일반적입니다. 이 글은 백엔드 개발자가 운영 환경에서 백업 전략을 정리할 때 참고할 수 있도록 절차와 선택 기준을 차분히 설명해요.

한눈에 보기

postgres 백업을 처음 정리할 때는 “무엇을 복구해야 하는가”를 먼저 정하는 편이 좋아요. 특정 테이블만 되살리고 싶은지, 데이터베이스 전체를 다른 서버로 옮기고 싶은지, 아니면 서버 장애 시 특정 시점으로 되돌리고 싶은지에 따라 도구가 달라집니다.

• 특정 데이터베이스나 객체 단위의 백업·이관에는 pg_dump가 적합해요.
• 역할, 테이블스페이스 같은 전역 객체까지 포함한 클러스터 논리 백업에는 pg_dumpall을 사용해요.
• 데이터 디렉터리 전체를 물리적으로 복사하려면 pg_basebackup을 사용해요.
• 장애 시점 복구, 즉 PITR까지 고려한다면 pg_basebackup과 WAL 아카이빙을 함께 구성해요.
• 어떤 방식이든 백업 파일을 만드는 것에서 끝내지 말고 정기적으로 복원 테스트를 해야 해요.

백업은 “데이터를 복사하는 작업”이 아니라 “복구 가능한 상태를 유지하는 운영 절차”로 이해하는 것이 좋아요. 백업 파일이 있어도 복원 절차를 모르거나 권한·확장 기능·역할 정보가 빠져 있으면 실제 장애 상황에서 쓸 수 없습니다. 그래서 백업 도구 선택만큼이나 복원 순서와 검증 방법을 문서로 남기는 일이 중요해요.

논리 백업과 물리 백업 비교

postgres 백업 방식은 크게 논리 백업과 물리 백업으로 나눌 수 있어요. 논리 백업은 데이터베이스 객체를 SQL이나 아카이브 형태로 추출하고, 물리 백업은 데이터 디렉터리와 WAL 파일을 그대로 다룹니다.

논리 백업은 백업 파일을 열어 어떤 객체가 들어 있는지 확인하기 쉽고, 특정 테이블만 복원하거나 다른 환경으로 옮길 때 편해요. 반면 물리 백업은 클러스터 전체를 빠르게 복구하는 데 초점이 맞춰져 있어서, 장애 복구 계획에는 물리 백업과 WAL 아카이빙을 함께 두는 경우가 많습니다. 두 방식은 경쟁 관계가 아니라 서로 다른 복구 시나리오를 담당하는 보완 관계로 보는 편이 좋아요.

단계별 백업 방법

pg_dump로 논리 백업

pg_dump는 특정 데이터베이스 하나를 논리적으로 덤프하는 도구예요. 기본 출력은 SQL 스크립트이지만, 사용자 지정 형식이나 디렉터리 형식을 사용하면 pg_restore로 유연하게 복원할 수 있습니다. 운영에서는 보통 사용자 지정 형식과 압축을 함께 쓰는 경우가 많아요.

예를 들어 사용자 지정 형식으로 백업하려면 pg_dump -Fc -f backup.dump mydb처럼 실행할 수 있어요. SQL 스크립트로 남기려면 pg_dump -f backup.sql mydb를 사용합니다. 백업 대상 데이터베이스에 접속할 권한이 있는 역할을 지정하고, 필요하면 호스트와 포트를 명시해요.

pg_dump는 백업 시점의 일관된 스냅숏을 기준으로 동작해요. 다만 테이블 잠금이나 동시 작업의 영향이 전혀 없는 것은 아니므로, 트래픽이 많은 시간대에는 백업 소요 시간과 잠금 영향을 확인하는 편이 좋아요. 대용량 데이터베이스라면 디렉터리 형식과 병렬 옵션을 검토할 수 있지만, 병렬 처리 수준은 서버 자원과 복원 환경을 함께 고려해야 합니다.

복원할 때는 pg_restore -d mydb backup.dump처럼 대상 데이터베이스를 지정해 실행해요. 기존 객체와 충돌할 수 있으므로 빈 데이터베이스에 복원하는지, 기존 객체를 정리할 것인지 미리 정해야 합니다. 소유자와 권한을 그대로 복원할지 여부도 --no-owner 같은 옵션으로 조정할 수 있어요.

pg_dumpall로 클러스터 전체 백업

pg_dumpall은 클러스터의 모든 데이터베이스를 논리적으로 덤프하고, 역할과 테이블스페이스 같은 전역 객체도 함께 포함해요. pg_dump가 데이터베이스 단위인 것과 달리, pg_dumpall은 클러스터 전체를 SQL 스크립트로 남기는 데 적합합니다.

pg_dumpall -f cluster.sql처럼 실행하면 전체 논리 백업을 만들 수 있어요. 복원은 psql -f cluster.sql로 실행하는 방식이 일반적입니다. 다만 데이터베이스가 많거나 크기가 큰 경우에는 백업과 복원에 시간이 오래 걸릴 수 있고, 개별 데이터베이스만 선택해서 복원하기는 어려워요.

pg_dumpall은 역할 정보를 포함하므로 계정과 권한을 함께 보존해야 하는 이관 작업에서 유용해요. 반대로 대용량 운영 환경에서는 전체 논리 백업보다 물리 백업을 기본으로 두고, 논리 백업은 보조 수단이나 이관 용도로 활용하는 편이 현실적입니다.

pg_basebackup으로 물리 백업

pg_basebackup은 실행 중인 postgres 클러스터의 데이터 디렉터리를 물리적으로 복사해요. WAL 파일도 함께 포함할 수 있어서, 백업 시점의 일관된 클러스터 상태를 확보하는 데 사용됩니다. 복제 연결을 사용하므로 서버 설정과 접속 권한을 미리 확인해야 해요.

예를 들어 tar 형식과 압축을 사용하려면 pg_basebackup -D /backup/base -Ft -z -P처럼 실행할 수 있어요. 백업이 끝나면 pg_verifybackup 같은 도구로 백업 무결성을 확인하는 절차를 두는 것이 좋아요. 물리 백업은 같은 주 버전의 postgres에서 복원하는 것을 전제로 하므로, 운영 버전과 복원 대상 버전의 호환성을 반드시 확인해야 합니다.

물리 백업은 데이터 디렉터리를 그대로 다루기 때문에 복원 절차가 단순해 보이지만, 실제로는 설정 파일, 테이블스페이스 경로, 권한, 서비스 관리 방식까지 함께 맞춰야 해요. 백업 파일만 복사해 두고 복원 절차를 검증하지 않으면 장애 시 예상치 못한 문제가 생길 수 있습니다.

WAL 아카이빙과 PITR

특정 시점으로 복구하려면 기본 백업과 WAL 아카이빙을 함께 구성해야 해요. postgres 공식 문서에서는 연속 아카이빙과 PITR을 위해 wal_level, archive_mode, archive_command 또는 아카이브 라이브러리 설정을 사용하는 방법을 설명합니다.

WAL 아카이빙은 데이터 변경 로그를 별도 저장소에 계속 보관하는 구조예요. 기본 백업을 만든 뒤 WAL 파일이 정상적으로 아카이빙되고 있는지 확인하고, 복원 시에는 기본 백업을 풀어 놓은 뒤 restore_command로 필요한 WAL을 가져오게 합니다. 특정 시점까지 복구하려면 recovery_target_time 같은 복구 목표를 지정할 수 있어요.

PITR의 핵심은 “백업본”과 “백업 이후의 WAL”이 모두 있어야 한다는 점이에요. WAL 아카이빙이 중간에 실패하면 원하는 시점으로 복구할 수 없으므로, 아카이빙 실패 알림과 보관 기간, 저장소 용량을 함께 관리해야 합니다. 또한 복구 목표 시점을 잘못 지정하면 의도한 시점과 다른 상태로 복구될 수 있으니, 장애 대응 문서에 복구 절차와 확인 순서를 미리 적어 두는 것이 좋아요.

상황별 선택 기준

운영 환경에서 postgres 백업 방식을 고를 때는 복구 목표와 운영 부담을 함께 봐야 해요. 모든 상황에 하나의 정답이 있는 것은 아니므로, 아래 기준으로 현재 시스템에 맞는 조합을 정리해 보세요.

• 작은 데이터베이스나 개발·스테이징 환경이라면 pg_dump 사용자 지정 형식 백업으로 시작할 수 있어요.
• 다른 서버로 데이터베이스를 옮기거나 특정 객체만 복원해야 한다면 논리 백업이 편해요.
• 클러스터 전체를 빠르게 복구해야 하는 운영 환경이라면 pg_basebackup을 기본으로 두는 편이 좋아요.
• 장애 시점 복구가 필요하다면 기본 백업과 WAL 아카이빙을 함께 구성하고 복원 훈련을 해야 해요.
• 계정과 권한을 포함한 전체 논리 이관이 필요하다면 pg_dumpall을 검토할 수 있어요.

논리 백업과 물리 백업을 동시에 운영하면 저장 공간과 관리 부담이 늘어나요. 그래서 백업 주기, 보관 기간, 복구 목표, 담당자를 정하고 각 백업의 역할을 명확히 나누는 것이 중요합니다. 예를 들어 일 단위 논리 백업은 이관과 부분 복구용으로, 물리 백업과 WAL 아카이빙은 장애 복구용으로 역할을 구분할 수 있어요.

복원 절차와 검증

백업의 가치는 복원이 성공할 때만 증명돼요. 백업 직후 파일 크기와 로그를 확인하는 것에서 끝내지 말고, 별도 환경에서 실제 복원을 수행해 보는 절차를 마련해야 합니다.

논리 백업은 빈 데이터베이스를 만들고 pg_restore 또는 psql로 복원한 뒤, 테이블 수와 주요 데이터, 인덱스, 시퀀스 값을 확인해요. 물리 백업은 복원 대상 서버의 데이터 디렉터리를 준비하고 백업을 풀어 놓은 뒤, 설정 파일과 권한을 맞추고 서버를 기동합니다. PITR 환경이라면 복구 목표 시점을 지정하고 WAL 적용 로그를 확인해야 해요.

복원 검증에는 다음 항목을 포함하는 것이 좋아요.

• 애플리케이션의 주요 쿼리가 정상 실행되는지 확인해요.
• 역할과 권한, 확장 기능이 복원 환경에 존재하는지 확인해요.
• 시퀀스와 기본 키 충돌이 없는지 확인해요.
• 복원 소요 시간과 실패 지점을 기록해요.
• 복원 후 백업 파일과 로그를 보관 정책에 따라 정리해요.

복원 테스트는 운영 데이터를 다루는 만큼 접근 권한과 마스킹 정책을 함께 정해야 해요. 테스트 환경에 운영 데이터를 그대로 복원할 경우 개인정보나 민감 정보가 노출되지 않도록 별도 절차를 마련하는 것이 안전합니다.

주의할 점

postgres 백업에서 자주 놓치는 부분은 백업 파일 자체보다 주변 정보예요. 데이터베이스 덤프에는 역할, 확장 기능, 외부 스키마, 애플리케이션 설정이 모두 포함되지 않을 수 있으므로 복원에 필요한 요소를 목록으로 관리해야 합니다.

또한 백업 파일을 운영 서버와 같은 장비에만 두면 서버 장애 시 백업까지 함께 잃을 수 있어요. 별도 스토리지나 다른 리전의 저장소에 보관하고, 전송 구간과 저장 구간의 암호화, 접근 권한, 보관 기간을 정해야 합니다. 백업 파일에는 민감 정보가 포함될 수 있으므로 누가 접근할 수 있는지도 최소화하는 편이 좋아요.

WAL 아카이빙을 사용한다면 아카이빙 실패를 감지하는 모니터링이 필수예요. 아카이브 명령이 실패하면 WAL 파일이 쌓이면서 디스크를 압박할 수 있고, 장애 복구 시 필요한 WAL이 비어 있을 수도 있습니다. 백업 성공 여부, 아카이브 지연, 저장소 용량, 복원 테스트 결과를 함께 관찰하는 것이 좋아요.

마지막으로 백업과 복원 절차를 문서화하고 정기적으로 리허설해야 해요. 담당자가 바뀌어도 같은 절차를 재현할 수 있도록 명령, 권한, 복원 순서, 롤백 기준을 남겨 두세요.

자주 묻는 질문

pg_dump와 pg_basebackup 중 무엇을 먼저 도입해야 하나요?

부분 복구와 이관이 중요하다면 pg_dump부터 도입하는 편이 쉬워요. 클러스터 전체 장애 복구가 목표라면 pg_basebackup과 WAL 아카이빙을 기본으로 잡고, 논리 백업을 보조로 두는 구성을 검토할 수 있습니다.

백업 파일은 운영 서버와 같은 곳에 두어도 되나요?

같은 장비에만 보관하면 서버 장애 시 백업도 함께 잃을 수 있어요. 별도 저장소에 보관하고 접근 권한과 암호화, 보관 기간을 정하는 것이 안전합니다.

PITR은 어떻게 준비하나요?

기본 백업과 WAL 아카이빙을 함께 구성하고, 복원 시 사용할 restore_command와 복구 목표 시점을 정해야 해요. 구성 후에는 별도 환경에서 원하는 시점으로 복구되는지 반드시 리허설해야 합니다.

논리 백업만으로 장애 복구가 가능한가요?

논리 백업만으로도 데이터 복원은 가능하지만, 장애 시점으로 정확히 되돌리는 PITR에는 물리 백업과 WAL 아카이빙이 필요해요. 복구 목표 수준에 따라 두 방식을 조합하는 것이 좋습니다.

출처

• PostgreSQL 공식 문서: Backup and Restore — https://www.postgresql.org/docs/current/backup.html
• PostgreSQL 공식 문서: pg_dump — https://www.postgresql.org/docs/current/app-pgdump.html
• PostgreSQL 공식 문서: pg_basebackup — https://www.postgresql.org/docs/current/app-pgbasebackup.html
• PostgreSQL 공식 문서: Continuous Archiving and Point-in-Time Recovery — https://www.postgresql.org/docs/current/continuous-archiving.html

관련 운영 글도 함께 읽어 보세요. PostgreSQL 운영 체크리스트: 백업·모니터링·복구 훈련에서 정기 점검 항목과 장애 대응 순서를 더 자세히 정리하고 있어요.