PostgreSQL 백업 자동화는 pg_dump 실행만 예약하는 것으로 끝나지 않습니다. 비밀번호 노출 방지, 실패한 파일의 구분, 보존 정책, 복구 검증과 모니터링이 함께 있어야 실제 사고에서 사용할 수 있습니다.
[목차]
백업 형식 선택
- Custom(
-Fc): 압축, 선택 복구와pg_restore사용이 가능해 일반적인 단일 DB 백업에 적합합니다. - Directory(
-Fd): 병렬 덤프와 병렬 복구가 필요한 큰 DB에 적합합니다. - Plain SQL: 사람이 읽기 쉽지만 선택 복구와 병렬 처리에는 제약이 있습니다.
비밀번호 파일을 안전하게 준비합니다
Linux에서는 실행 계정의 ~/.pgpass 또는 PGPASSFILE로 지정한 파일에 다음 형식을 사용합니다.
db.example.com:5432:appdb:backup_user:replace-with-secret
chmod 600 ~/.pgpass
비밀번호를 명령행 인수나 스크립트 본문에 직접 넣지 않습니다. 백업 계정에는 필요한 최소 권한만 부여하세요.
Custom 형식 자동화 예제
#!/usr/bin/env bash
set -Eeuo pipefail
umask 077
backup_dir="/srv/backups/postgresql"
stamp="$(date -u +%Y%m%dT%H%M%SZ)"
tmp="$backup_dir/.appdb-$stamp.dump.tmp"
dest="$backup_dir/appdb-$stamp.dump"
mkdir -p "$backup_dir"
trap 'rm -f "$tmp"' EXIT
pg_dump \
--host=db.example.com \
--username=backup_user \
--dbname=appdb \
--format=custom \
--file="$tmp"
pg_restore --list "$tmp" > /dev/null
mv "$tmp" "$dest"
trap - EXIT
find "$backup_dir" -type f -name 'appdb-*.dump' -mtime +30 -delete
printf 'backup complete: %s\n' "$dest"
pg_restore --list는 아카이브 구조를 읽을 수 있는지 확인하지만 전체 복구 성공을 보장하지는 않습니다. 운영과 분리된 DB에 정기적으로 복원해 애플리케이션의 핵심 쿼리까지 시험해야 합니다.
복구 시험
createdb --template=template0 appdb_restore_test
pg_restore \
--exit-on-error \
--clean --if-exists \
--dbname=appdb_restore_test \
/srv/backups/postgresql/appdb-20260827.dump
소유자와 권한을 다른 환경에서 복원한다면 --no-owner, --role 같은 옵션을 환경에 맞게 검토합니다. 운영 DB를 대상으로 복구 명령을 처음 시험하면 안 됩니다.
놓치기 쉬운 항목
pg_dump클라이언트가 서버의 더 새로운 메이저 버전을 지원하는지 확인합니다.- 역할과 테이블스페이스 등 클러스터 전역 객체는
pg_dumpall --globals-only로 별도 보관합니다. - 백업 용량, 종료 코드와 마지막 성공 시간을 모니터링합니다.
- DB 서버와 다른 장애 영역에 암호화된 사본을 둡니다.
공식 참고자료
관련 글
내용 검토 및 업데이트: 2026년 8월 27일