목차
백업 전 준비
이 글은 PostgreSQL이 설치되어 있고, 백업 대상 데이터베이스에 접속할 권한이 있다고 가정합니다. 명령어는 Linux 또는 macOS 터미널 기준이며, Windows에서는 PostgreSQL의 bin 폴더에서 실행할 수 있습니다.
백업 파일을 저장할 디렉터리를 먼저 만들고 접속 정보를 확인하세요. 비밀번호는 명령어에 직접 넣기보다 실행 후 입력하는 방식이 안전합니다.
mkdir -p ~/postgres-backups
pg_dump --version
psql -h localhost -U dbuser -d appdb -c "SELECT version();"
pg_dump로 백업하기
운영 데이터베이스를 중단하지 않고 논리 백업(테이블과 데이터를 SQL 명령 형태로 저장하는 방식)을 만들 수 있습니다. 다만 이 “SQL 명령 형태”는 --format=plain(기본값)으로 저장했을 때의 모습이고, 아래에서 쓸 --format=custom(사용자 지정 형식)은 같은 논리 백업이라도 사람이 읽을 수 있는 SQL문이 아니라 pg_restore 전용 바이너리 아카이브로 저장된다는 점이 다릅니다. 복구와 부분 선택이 편리한 사용자 지정 형식으로 저장해 보겠습니다.
pg_dump -h localhost -U dbuser -d appdb \
--format=custom \
--file=~/postgres-backups/appdb.dump
백업이 끝나면 파일 존재 여부와 크기를 확인합니다. 백업 파일을 같은 디스크에만 두면 디스크 고장이나 삭제 사고에 함께 영향을 받으므로 NAS나 다른 저장소에도 복사하세요.
ls -lh ~/postgres-backups/appdb.dump
pg_restore로 복구하기
복구 대상 데이터베이스를 비어 있는 상태로 준비한 뒤 pg_restore를 실행합니다. 대상 데이터베이스가 없다면 먼저 생성하고, 기존 데이터베이스에 덮어쓸 때는 데이터 손실 범위를 확인한 뒤 진행해야 합니다.
createdb -h localhost -U dbuser restored_appdb
본격적으로 복구하기 전에, 아카이브 파일 자체가 정상인지 가볍게 먼저 확인할 수 있습니다. --list 옵션은 실제로 아무것도 복구하지 않고 아카이브 안에 어떤 테이블·인덱스·시퀀스가 들어있는지 목차만 출력합니다.
pg_restore --list ~/postgres-backups/appdb.dump
이 명령이 오류 없이 목차를 정상 출력하면 아카이브를 읽을 수 있는지에 대한 최소한의 1차 확인이 됩니다. 다만 이건 파일이 읽히는지만 보는 가벼운 1차 점검이며, 데이터가 실제로 제대로 복구되는지는 이어서 실행할 전체 복구로 확인해야 합니다.
pg_restore -h localhost -U dbuser -d restored_appdb \
--no-owner \
~/postgres-backups/appdb.dump
복구 후 테이블과 데이터가 들어왔는지 확인합니다. --no-owner는 원본 소유자 계정이 복구 서버에 없을 때 권한 오류를 줄이는 옵션이며, 운영 권한 정책에 맞게 적용해야 합니다.
psql -h localhost -U dbuser -d restored_appdb \
-c "\dt"
psql -h localhost -U dbuser -d restored_appdb \
-c "SELECT count(*) FROM public.example_table;"
실패를 줄이는 점검법
복구 대상에 같은 테이블이 이미 있으면 relation already exists 같은 오류가 나타날 수 있습니다. 이 경우 빈 데이터베이스를 새로 만들거나, 기존 데이터를 지워도 되는 상황에서만 --clean --if-exists 옵션을 검토하세요.
pg_restore -h localhost -U dbuser -d restored_appdb \
--clean --if-exists --no-owner \
~/postgres-backups/appdb.dump
또 다른 원인은 원본에만 존재하는 사용자와 권한입니다. pg_dump는 일반적으로 데이터베이스 안의 객체를 저장하지만 서버 전체 역할(role) 정보까지 보존하지는 않으므로, 필요하면 별도로 확인합니다.
pg_dumpall -h localhost -U dbuser --globals-only \
> ~/postgres-backups/globals.sql
pg_dump는 논리 백업이라 특정 시점으로 즉시 되돌리는 기능이나 서버 전체 장애를 자동으로 막는 기능은 없습니다. 백업 파일을 다른 저장소에 보관하고, 실제 복구 테스트까지 수행해야 백업의 유효성을 확인할 수 있습니다.
실제 운영에서 pg_dump를 쓴 사례
이 글에서 설명한 것과 같은 방식의 pg_dump를 실제 운영 중인 서비스에서 사용한 사례가 있습니다. 도메인 전환 작업을 앞두고 관련 테이블 두 개를 일괄 수정하기 전, 되돌릴 수 있는 지점을 남기기 위해 각 테이블을 대상으로 pg_dump를 실행해 압축 백업 파일을 만들었습니다. 이때는 전체 데이터베이스(-d appdb)가 아니라 -t 옵션으로 대상 테이블만 지정해 각각 백업했습니다 — 이 사례에서는 수정 대상 테이블만 되돌리면 충분했기 때문입니다. 다만 이 방식은 두 테이블 안의 변경만 되돌릴 수 있을 뿐, 데이터베이스 전체를 대상으로 하는 백업을 대신하지는 않습니다. 백업은 대량 수정 작업 바로 직전에 실행했고, 파일은 이후 계속 보관하고 있습니다. 이 사례는 백업을 만든 시점과 목적을 보여줄 뿐, 이 글의 pg_restore 절차까지 실제로 수행했다는 뜻은 아닙니다 — 수정 작업이 문제없이 끝나 복구가 필요한 상황 자체가 생기지 않았습니다.
결론
pg_dump로 백업하고 빈 데이터베이스에 pg_restore로 복구하면 기본적인 PostgreSQL 데이터 보호 흐름을 만들 수 있습니다. 파일 복사와 복구 테스트를 함께 운영해야 실전 대응력이 생깁니다.