백업 파일이 있다는 것과 복구할 수 있다는 것은 다릅니다

PostgreSQL 운영에서 백업은 파일 생성으로 끝나지 않습니다. 장애 시 필요한 것은 특정 시점의 데이터를 정해진 시간 안에 별도 환경으로 되살리는 능력입니다. 백업 파일이 손상됐거나, 권한과 확장 모듈이 빠졌거나, 애플리케이션이 기대하는 역할과 스키마가 복원되지 않으면 백업은 있어도 서비스 복구에는 실패합니다. 따라서 백업 정책에는 생성 주기뿐 아니라 복구 테스트 주기, 보관 기간, 복구 책임자, 목표 복구 시간(RTO)을 포함해야 합니다.

가장 먼저 데이터베이스 전체 백업과 업무 데이터 백업의 범위를 구분합니다. 단일 데이터베이스 덤프는 테이블과 데이터 복원에는 적합하지만, 로그인 역할·테이블스페이스·전역 권한은 포함하지 않습니다. 서버 이전이나 재해 복구를 대비한다면 역할 정보를 별도로 백업하고, 복원 대상 PostgreSQL의 메이저 버전과 필요한 확장 모듈도 점검해야 합니다.

운영에 적합한 custom 형식 백업 만들기

작은 데이터베이스는 SQL 텍스트 덤프로도 충분할 수 있지만, 운영 환경에서는 custom 형식이 유리합니다. 압축이 가능하고, pg_restore로 테이블·스키마·데이터 항목을 선택 복원할 수 있으며, 복원 병렬 처리도 사용할 수 있습니다. 백업 작업은 서비스 계정과 분리된 권한으로 실행하고, 파일 권한을 제한된 위치에 보관합니다.

#!/usr/bin/env bash
set -euo pipefail

BACKUP_DIR=/var/backups/postgresql
STAMP=$(date +%F_%H%M%S)
mkdir -p "$BACKUP_DIR"

pg_dump \
  --format=custom \
  --file="$BACKUP_DIR/app_${STAMP}.dump" \
  --dbname="postgresql://[email protected]:5432/appdb"

pg_dumpall --globals-only \
  --file="$BACKUP_DIR/globals_${STAMP}.sql"

find "$BACKUP_DIR" -type f -mtime +14 -delete

비밀번호를 명령행 인수나 스크립트에 직접 넣으면 프로세스 목록과 저장소에 남을 수 있습니다. 실행 계정의 .pgpass를 권한 0600으로 설정하거나, 배포 환경의 비밀 관리 기능을 사용합니다. 삭제 정책은 복제본 또는 원격 보관 성공을 확인한 뒤 적용해야 하며, 단순히 오래된 파일만 지우는 방식은 장기 장애를 발견하기 어렵습니다.

복구 전에는 백업 목록과 무결성을 확인합니다

백업 완료 직후 파일 크기만 확인하면 빈 덤프나 중간 실패를 놓칠 수 있습니다. pg_restore --list는 custom 형식의 목차를 읽어 백업이 실제로 해석되는지 확인합니다. 매일 생성한 백업에 대해 이 검사를 수행하고, 결과와 파일의 SHA-256 값을 운영 로그에 남겨 두면 저장소 전송 오류를 추적하기 쉽습니다.

BACKUP=/var/backups/postgresql/app_2026-08-28_001500.dump
pg_restore --list "$BACKUP" > /tmp/app-backup-toc.txt
shasum -a 256 "$BACKUP" > "${BACKUP}.sha256"
grep -E 'TABLE DATA|EXTENSION' /tmp/app-backup-toc.txt | head -20

목차에 필요한 스키마와 테이블 데이터가 있는지 확인하고, 애플리케이션이 사용하는 uuid-ossp, pgcrypto, vector 같은 확장이 있다면 대상 서버에 설치 가능한지 미리 확인합니다. 대용량 데이터베이스에서 논리 백업 시간이 업무 시간과 겹치면 부하가 커질 수 있으므로, 백업 창과 I/O 사용량을 관찰해야 합니다. 더 짧은 복구 시점과 물리 복제를 요구하는 환경은 WAL 아카이빙과 PITR 전략을 별도로 설계합니다.

격리된 검증 데이터베이스로 정기 복구 테스트하기

복구 테스트는 운영 서버에 덮어쓰지 않습니다. 같은 메이저 버전의 PostgreSQL을 가진 격리 환경에 검증용 데이터베이스를 만들고, 역할 정보와 덤프를 순서대로 복원합니다. 기존 객체가 남아 있어 결과가 왜곡되지 않도록 매번 새 데이터베이스를 사용합니다. pg_restore의 --clean 옵션은 대상 객체를 삭제할 수 있으므로, 검증 환경에서만 사용해야 합니다.

createdb -h 127.0.0.1 -U restore_admin appdb_restore_check
psql -h 127.0.0.1 -U restore_admin -f /var/backups/postgresql/globals_2026-08-28_001500.sql postgres
pg_restore \
  --host=127.0.0.1 --username=restore_admin \
  --dbname=appdb_restore_check \
  --jobs=4 --verbose \
  /var/backups/postgresql/app_2026-08-28_001500.dump
psql -h 127.0.0.1 -U restore_admin -d appdb_restore_check \
  -c "SELECT now(), count(*) FROM public.orders;"

복원 명령이 종료 코드 0으로 끝났다고 바로 성공으로 판단하지 않습니다. 핵심 테이블의 행 수, 최근 데이터의 날짜 범위, 주요 인덱스와 확장 모듈, 애플리케이션의 읽기 전용 헬스 체크를 함께 확인합니다. 개인정보가 들어간 운영 덤프를 테스트 환경으로 복원할 경우 접근 권한을 더 좁히고, 개발자가 필요 이상으로 데이터를 열람하지 않도록 마스킹 또는 별도 검증 절차를 마련합니다.

복구 절차를 운영 문서로 고정하는 방법

사람이 바뀌어도 복구가 가능하도록 명령, 경로, 필요한 권한, 예상 소요 시간을 런북에 기록합니다. 정기 테스트에서는 시작 시각과 종료 시각을 남겨 실제 RTO를 계산하고, 실패한 객체와 원인을 티켓으로 관리합니다. 프로덕션 DB에 데이터가 늘었는데 백업 용량과 복원 시간이 함께 늘지 않는다면 백업 범위가 잘못됐을 가능성도 점검해야 합니다. 백업 담당자가 휴가 중인 경우에도 다른 운영자가 동일한 절차를 재현할 수 있는지가 마지막 점검 기준입니다.

운영 체크리스트

  • custom 형식 덤프와 전역 역할 백업을 분리해 보관한다.
  • 백업 생성 뒤 pg_restore --list와 해시 검증을 자동화한다.
  • 운영과 격리된 환경에서 정기적으로 실제 복원을 수행한다.
  • 핵심 테이블·확장 모듈·애플리케이션 조회까지 검증한다.
  • 복원 시간과 실패 원인을 기록해 RTO와 절차를 계속 보완한다.