PostgreSQL 복구 시나리오별 복원 절차 요약

소개

이 문서는 운영 환경에서 흔히 마주치는 PostgreSQL 복구 시나리오별로 실무적인 복원 절차를 정리한다. 처음 접하는 사용자도 이해하기 쉽게 베이스 백업과 WAL(Write-Ahead Log) 기반 PITR(Point-In-Time Recovery)의 개념을 짚고, 각 상황에 맞는 단계별 명령과 검증 방법을 제시한다.

복구의 기본 개념

베이스 백업과 WAL 아카이빙

베이스 백업은 특정 시점의 데이터 디렉터리 전체 스냅샷이다. WAL은 그 이후의 모든 변경 로그를 담는다. PITR은 베이스 백업과 아카이브된 WAL을 결합해 원하는 시점으로 복원하는 방식이다.

복원 유형 요약

• 전체 장애(서버/디스크 손실): 베이스 백업 + WAL 적용
• 시점 복원(PITR): 특정 시점 또는 트랜잭션 이전으로 복원
• 단일 객체 복구: 테이블/스키마 단위 복구(논리적 백업 또는 PITR 이용)
• 파일 손상/데이터 불일치: 손상 범위에 따라 파일 교체 또는 전체 복원

사전 준비

• 정기 베이스 백업(예: pg_basebackup 또는 파일시스템 스냅샷)
• WAL 아카이빙 설정(archive_mode=on, archive_command 지정)
• 백업과 WAL 보관 정책 및 검증 주기

시나리오별 복원 절차

1) 전체 서버/디스크 손실 복구

가장 일반적인 절차는 베이스 백업 복원 후 WAL을 적용해 최신 상태로 복원하는 것이다. 주요 단계는 아래와 같다.

• 베이스 백업 복사/복원
• restore_command 설정으로 WAL 아카이브를 가져오도록 구성
• recovery signal 설정 후 PostgreSQL 시작
• 복원 완료 후 정상 동작 확인

예시: pg_basebackup으로 백업을 만든 경우

pg_basebackup -D /var/lib/postgresql/12/main -F tar -z -P -X fetch -h backup-host -U backupuser

복원 시 복원한 데이터 디렉터리에 아래와 같은 복구 설정을 둔다(버전 12 이상 기준).

# postgresql.conf 또는 postgresql.auto.conf에 추가
restore_command = 'cp /mnt/wal_archive/%f %p'
recovery_target_time = '2025-01-30 15:20:00'
# 복구를 트리거하려면 recovery.signal 파일 생성

이후 PostgreSQL을 시작하면 restore_command로 WAL을 적용하면서 recovery_target_time까지 복원한다.

2) 시점 복원(PITR)

PITR은 실수로 데이터 삭제나 잘못된 배치 실행 등에서 유용하다. 핵심은 복원 시점(target)을 정확히 지정하는 것이다.

• 베이스 백업 위치와 복원 가능한 WAL 범위 확인
• 복원 대상 시점 결정(시간, 트랜잭션 ID, 명령 포함 여부)
• restore_command와 recovery_target_* 옵션 설정
• 복구 완료 후 필요한 데이터만 덤프하여 적용하거나 전체 데이터베이스로 전환

recovery_target 설정 예시

recovery_target_time = '2025-01-30 15:19:30'
# 또는 트랜잭션 ID로 지정
recovery_target_xid = '12345'

3) 단일 객체(테이블) 복구

테이블 하나만 복구할 때는 논리적 백업(pg_dump)이나 PITR로 시점 복원 후 필요한 객체만 추출하는 방식이 있다. 운영 중인 데이터베이스에서 바로 복구가 불가능할 수 있으므로 스탠바이 복원 및 덤프 방식이 안전하다.

• 방법 A: 정기적 pg_dump에서 테이블 복원
• 방법 B: PITR로 별도 서버에 시점 복원 후 pg_dump로 필요한 테이블 추출

4) 파일 손상 또는 데이터 파일 불일치

데이터 파일 손상은 범위가 중요하다. 일부 파일만 손상되면 해당 테이블스페이스나 테이블을 복원하고 남은 부분은 온라인으로 유지할 수 있다. 그러나 메타데이터 손상은 전체 복원이 필요할 수 있다.

• 손상된 파일 식별 후 해당 테이블/인덱스 재작성
• 가능하면 스냅샷 기반 복원 또는 베이스 백업으로 전체 교체
• 복원 후 VACUUM 및 인덱스 재구성으로 무결성 검사

검증과 마무리 작업

복원 검증 항목

• 서비스 정상 시작 여부 및 로그 확인
• 데이터 일관성 확인(샘플 쿼리, 레코드 수 비교)
• 애플리케이션 연결 및 성능 확인

복구 후 권장 작업

• 최신 상태에서 새로운 베이스 백업 생성
• 재발 방지를 위한 백업/아카이브 정책 검토
• 복구 절차 점검표와 자동화 스크립트 정비

실무 팁과 체크리스트

• 정기적으로 베이스 백업과 WAL 아카이브의 복원 테스트 수행
• restore_command는 테스트 환경에서 먼저 검증
• 복원 타임라인과 보관 기간을 운영 정책으로 명확히 정의
• 로그 보존과 모니터링으로 이상 징후 조기 감지

결론

PostgreSQL 복원은 베이스 백업과 WAL 아카이빙의 조합으로 대부분의 시나리오를 다룰 수 있다. 시나리오별로 절차를 정리해 두면 장애 발생 시 복구 시간과 리스크를 크게 줄일 수 있다. 마지막으로 복구 절차는 문서화하고 정기적으로 연습해 실전에서 신뢰성 있게 동작하는지 확인해야 한다.