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

postgres 백업 복원은 운영 데이터베이스에서 장애와 실수를 되돌리기 위한 기본 절차예요. 핵심은 논리 백업과 물리 백업을 구분하고, 복원 목표에 따라 pg_dump, pg_basebackup, PITR를 선택하는 것이에요. 이 글은 공식 문서에서 확인한 범위를 기준으로 백업과 복원 흐름을 정리해요.

한눈에 보기

백업은 “무엇을 되돌릴 것인가”에 따라 도구가 달라져요. 특정 데이터베이스나 테이블만 옮기려면 논리 백업이 편하고, 클러스터 전체를 빠르게 복구하거나 장애 시점으로 되돌리려면 물리 백업과 WAL 아카이브를 함께 준비해야 해요.

논리 백업은 pg_dump와 pg_dumpall로 수행해요. 스키마와 데이터를 SQL 또는 아카이브 형식으로 내보내요.
물리 백업은 pg_basebackup으로 수행해요. 데이터 디렉터리 수준에서 클러스터를 복사해요.
논리 복원은 pg_restore 또는 psql로 수행해요. 물리 복원은 데이터 디렉터리를 교체하고 서버를 다시 시작해요.
PITR는 베이스 백업과 연속 보관한 WAL 파일을 조합해 특정 시점으로 복구하는 방식이에요.
백업 성공 여부보다 중요한 것은 실제 복원 리허설이에요. 운영 환경과 같은 조건에서 복원해 보지 않으면 백업의 유효성을 알기 어려워요.

백업 방식 비교 표

아래 표는 운영에서 자주 비교하는 논리 백업, 물리 백업, PITR의 차이를 정리한 것이에요. 백업 도구 자체보다 “복원 단위”와 “복구 목표”를 먼저 정하면 선택이 쉬워져요.

항목	논리 백업	물리 백업	PITR
주요 도구	`pg_dump`, `pg_dumpall`	`pg_basebackup`	베이스 백업과 WAL 아카이브
백업 단위	데이터베이스, 스키마, 테이블	클러스터의 데이터 파일	베이스 백업 시점과 WAL 구간
복원 단위	객체를 다시 생성하고 데이터를 적재	데이터 디렉터리 교체	베이스 백업 복원 후 WAL 재생
장점	특정 객체만 다루기 쉽고 형식을 검토하기 좋아요	전체 인스턴스를 한 흐름으로 복구하기 좋아요	장애 직전이나 특정 시점으로 되돌릴 수 있어요
주의점	대용량에서는 시간이 오래 걸릴 수 있어요	서버 설정과 권한, 저장 공간을 함께 봐야 해요	WAL 보관이 끊기면 목표 시점 복구가 어려워요
적합한 상황	개발 데이터 이관, 단일 DB 백업	전체 클러스터 백업, 재해 복구	데이터 오입력, 특정 시점 복구

단계별 백업과 복원 방법

논리 백업: pg_dump와 pg_dumpall

pg_dump는 특정 데이터베이스의 스키마와 데이터를 내보내요. 사용자 정의 형식으로 백업하면 pg_restore에서 선택적으로 복원하기 편해요.

pg_dump -Fc -f mydb.dump mydb

SQL 텍스트로 백업하려면 다음과 같이 실행해요. 사람이 내용을 확인하거나 다른 환경에서 단순 적용할 때 유용해요.

pg_dump -Fp -f mydb.sql mydb

클러스터 전체를 SQL로 백업하려면 pg_dumpall을 사용해요. 역할과 같은 전역 객체를 함께 다룰 때 필요해요.

pg_dumpall -f cluster.sql

역할과 권한만 따로 백업하려면 전역 객체만 덤프할 수 있어요.

pg_dumpall --globals-only -f globals.sql

논리 복원: pg_restore와 psql

사용자 정의 형식 아카이브는 pg_restore로 복원해요. 대상 데이터베이스를 먼저 만들고 연결하는 방식이 일반적이에요.

createdb mydb_restore

pg_restore -d mydb_restore mydb.dump

SQL 텍스트 백업은 psql로 적용해요.

psql -d mydb_restore -f mydb.sql

기존 객체를 정리하면서 복원해야 한다면 --clean과 --if-exists를 검토해요. 다만 운영 데이터베이스에 그대로 적용하기 전에 반드시 별도 환경에서 결과를 확인해야 해요.

pg_restore --clean --if-exists -d mydb_restore mydb.dump

전역 객체 백업은 복원 대상 클러스터에서 psql로 적용해요. 역할이 이미 존재하면 충돌할 수 있으므로 적용 전에 현재 상태를 확인해요.

psql -d postgres -f globals.sql

물리 백업: pg_basebackup

pg_basebackup은 실행 중인 PostgreSQL 서버에서 베이스 백업을 만들어요. 복제 연결과 파일 저장 공간이 필요하고, 백업 대상 디렉터리에 대한 권한도 확인해야 해요.

pg_basebackup -D /backup/base -Ft -z -P

물리 백업은 데이터 파일을 그대로 복사하므로 클러스터 전체 복구에 적합해요. 대신 백업 시점 이후의 변경을 되돌리려면 WAL 아카이브가 함께 있어야 해요.

물리 복원과 PITR

물리 복원은 서버를 중지한 뒤 기존 데이터 디렉터리를 백업본으로 교체하는 흐름이에요. 데이터 디렉터리의 소유자와 권한, 설정 파일, Tablespace 위치를 함께 확인해야 해요.

PITR를 위해서는 postgresql.conf에 restore_command를 설정하고 recovery.signal 파일을 만들어 서버를 시작해요. 예를 들어 WAL 아카이브를 파일 시스템에 보관했다면 다음과 같은 형태로 지정해요.

restore_command = 'cp /archive/%f %p'

특정 시점으로 복구하려면 recovery_target_time 같은 목표를 설정해요. 정확한 시각은 장애 시점과 WAL 보관 범위를 기준으로 정하고, 복구 후에는 서버 로그에서 WAL 재생이 의도한 지점에서 멈췄는지 확인해요.

상황별 선택 기준

특정 데이터베이스만 다른 환경으로 옮길 때는 pg_dump -Fc가 편해요. 필요한 객체만 골라 복원할 수 있고, SQL 텍스트보다 관리가 수월해요.
역할과 권한까지 포함해 클러스터 전체를 백업하려면 pg_dumpall을 검토해요. 데이터베이스별 백업과 전역 객체 백업을 나누어 보관하는 방법도 좋아요.
전체 인스턴스를 빠르게 복구해야 한다면 pg_basebackup이 적합해요. 데이터 파일을 그대로 복사하므로 복원 절차가 단순한 편이에요.
데이터 오입력이나 잘못된 배포 직전으로 되돌려야 한다면 PITR를 준비해요. 베이스 백업과 WAL 아카이브가 모두 있어야 목표 시점 복구가 가능해요.
스키마 변경을 검토하거나 마이그레이션 SQL을 확인하려면 일반 SQL 백업이 유용해요. 다만 대용량에서는 복원 시간이 길어질 수 있어요.
운영 장비와 다른 저장소에 백업을 보관하고, 정기적으로 복원 리허설을 수행하는 것이 안전해요.

주의할 점

논리 백업은 데이터베이스 객체를 내보내는 방식이라 역할이나 일부 전역 객체가 자동으로 포함되지 않아요. pg_dumpall --globals-only 같은 별도 백업을 함께 준비해야 하는 이유예요.

물리 백업은 서버 설정과 데이터 디렉터리 구조에 의존해요. 복원 대상 서버의 경로, 권한, Tablespace 구성이 원본과 다르면 추가 조정이 필요할 수 있어요.

PITR는 WAL 연속성이 핵심이에요. 아카이브가 중간에 끊기거나 보관 공간이 부족하면 원하는 시점까지 복구하지 못할 수 있어요. WAL 보관 상태와 디스크 여유 공간을 함께 감시해야 해요.

백업 파일과 WAL을 같은 장비에만 두지 않는 것이 좋아요. 장비 장애나 랜섬웨어 같은 상황을 고려해 별도 저장소와 접근 제어를 마련해요.

복원 후에는 애플리케이션 연결, 역할과 권한, 확장 기능, 시퀀스 값, 주요 테이블의 데이터와 쿼리 결과를 확인해요. 가능하면 실제 서비스 전환 전에 같은 절차를 다시 리허설하는 것이 좋아요.

복원 후 검증

복원이 끝났다는 것과 서비스가 정상이라는 것은 다른 문제예요. 복원한 데이터베이스에서 연결 테스트와 읽기 테스트를 수행하고, 애플리케이션이 기대하는 스키마와 권한이 맞는지 확인해요.

주요 테이블의 행 수와 최근 변경 데이터를 대조하고, 인덱스와 제약 조건이 정상적으로 생성됐는지도 봐요. 확장 기능을 사용한다면 복원 대상 서버에 같은 확장이 설치되어 있는지 먼저 확인해야 해요.

시퀀스 값이 백업 시점과 어긋나면 새 데이터 입력 시 충돌이 생길 수 있어요. 복원 후 쓰기 테스트를 수행하고, 필요하면 시퀀스 값을 현재 데이터에 맞게 조정해요.

자주 묻는 질문

pg_dump와 pg_basebackup은 무엇이 다른가요?

pg_dump는 데이터베이스 객체를 SQL이나 아카이브 형식으로 내보내는 논리 백업 도구이고, pg_basebackup은 클러스터의 데이터 파일을 그대로 복사하는 물리 백업 도구예요. 특정 데이터베이스만 옮기거나 스키마를 검토할 때는 pg_dump가 편하고, 전체 인스턴스 복구와 PITR를 준비할 때는 pg_basebackup과 WAL 아카이브를 함께 사용해요.

백업 파일만 있으면 항상 완전 복구가 가능한가요?

백업 파일의 종류와 보관 범위에 따라 달라요. 논리 백업은 백업 시점의 데이터로 되돌리는 데 유리하지만, 그 이후의 변경은 별도 로그 없이는 반영할 수 없어요. PITR를 위해서는 베이스 백업과 연속 보관한 WAL 파일이 함께 있어야 해요.

복원 후에는 무엇을 확인해야 하나요?

애플리케이션 연결, 역할과 권한, 확장 기능, 시퀀스 값, 주요 테이블의 데이터와 쿼리 결과를 확인해요. 백업 전후의 스키마 차이와 데이터 정합성을 비교하고, 복원한 데이터베이스에서 쓰기 테스트도 수행해요. 가능하면 실제 서비스 전환 전에 같은 절차를 다시 리허설하는 것이 좋아요.

출처

관련 운영 글은 PostgreSQL 운영 체크리스트에서 이어서 확인하실 수 있어요.