본문으로 건너뛰기
11.7 복구 시나리오와 정기 복구 훈련

11.7 복구 시나리오와 정기 복구 훈련

백업 자체보다 복구가 실제로 가능한지가 운영의 진짜 관문입니다. 자주 마주치는 6가지 복구 시나리오와 각각의 절차, 그리고 정기 복구 훈련의 자동화를 봅니다.

시나리오 A — 실수로 테이블 DROP

가장 흔한 사고입니다. 누군가 DROP TABLE orders;를 운영에서 실행합니다.

대응 결정

옵션메모
새 클러스터에 PITR 후 테이블만 dump → 운영에 import가장 안전. 약 1~2시간
운영 클러스터 자체 PITR그 사이 트랜잭션 모두 사라짐 — 거의 안 함
dump가 있으면 그 dump의 테이블만 restore최근 dump 시점까지만 데이터

표준 절차

# 1. 새 호스트에 PITR (drop 1분 전으로)
sudo -u postgres pgbackrest --stanza=main restore \
  --type=time --target='2026-05-23 09:54:00' \
  --target-action=promote

# 2. 기동 후 테이블만 dump
pg_dump -h staging -t public.orders app_main > orders_recovered.sql

# 3. 운영에 재생
psql -h primary app_main < orders_recovered.sql

DROP 자체는 PITR로 되살리지만, 그 사이 진행된 다른 트랜잭션과의 충돌은 운영자가 판단합니다.

시나리오 B — UPDATE/DELETE 사고

UPDATE orders SET status = 'cancelled';를 WHERE 없이 실행한 경우.

절차

A와 동일 — staging PITR → 영향 받은 row만 export → 운영 patch.

# staging에서
psql -h staging -c "
COPY (SELECT * FROM orders WHERE updated_at > '2026-05-23 09:50:00')
  TO '/tmp/before.csv' WITH CSV;
"

# 운영에서
\COPY orders_before FROM '/tmp/before.csv' WITH CSV;

UPDATE orders o SET status = b.status FROM orders_before b WHERE o.id = b.id;

시나리오 C — 클러스터 전체 손실 (디스크 사고)

호스트 자체 + 디스크 사고입니다. 새 호스트에서 처음부터 복원.

절차

# 1. 새 호스트에 PostgreSQL 설치
sudo dnf install postgresql17-server pgbackrest

# 2. pgBackRest 설정 복사 (저장소 위치·인증)
sudo scp old_admin:/etc/pgbackrest.conf /etc/

# 3. 새 PGDATA 디렉토리 (비어 있어야)
sudo -u postgres mkdir -p /var/lib/pgsql/17/data
sudo chmod 0700 /var/lib/pgsql/17/data

# 4. 가장 최근 백업 복원
sudo -u postgres pgbackrest --stanza=main restore

# 5. 기동
sudo systemctl start postgresql-17

# 6. 검증
psql -c "SELECT count(*) FROM critical_table;"

RTO 측정 — 운영 권장은 1시간 이내 전체 복원. 클러스터가 크면 미리 standby가 있어야 합니다.

시나리오 D — 운영 standby로 즉시 failover

primary 호스트 자체 사고입니다. 미리 운영하던 standby를 promote.

절차

# standby에서
sudo -u postgres pg_ctl -D /var/lib/pgsql/17/data promote

promote 후 standby가 새 timeline 시작 + read-write. 클라이언트 연결을 새 호스트로 전환 (DNS, HAProxy, pgBouncer 등).

자동화: Patroni·repmgr·pg_auto_failover (Part XII).

시나리오 E — 한 테이블이 corrupt

could not read block X in file ... 오류 발생합니다. data_checksums = on이면 잘 감지.

절차

# 1. corrupt 페이지 위치 확인
psql -c "SELECT ctid, * FROM bad_table LIMIT 1;"  # 어디가 깨졌는지

# 2. 영향 받는 row 추출 (가능한 만큼)
SELECT * FROM bad_table WHERE ctid::text NOT LIKE '(<bad_page>,%)';

# 3. 최근 백업에서 같은 테이블 export
pgbackrest --stanza=main restore --tablespace-map=... --type=immediate ...
# 그 staging에서
pg_dump -t bad_table app_main > recover.sql

# 4. 운영의 corrupt 테이블 교체
DROP TABLE bad_table;
\i recover.sql

데이터 디스크 자체 의심이면 OS 진단 (smartctl, dmesg)도 같이.

시나리오 F — 데이터센터 장애

전체 리전 사고입니다. 다른 리전·다른 클라우드로 복구합니다.

절차 — 오프사이트 백업이 있다면

# 1. 다른 리전·클라우드에 PostgreSQL 설치
# 2. S3 cross-region 또는 그 리전의 백업 저장소에서 pgBackRest restore
# 3. DNS·CDN·LB 전환

RTO·RPO 모두 가장 큽니다. 3-2-1 원칙(11.1)이 지켜진 상황에서만 가능합니다.

정기 복구 훈련 — 자동화

백업의 90% 실패 사례는 훈련 부족입니다. 분기마다 자동 훈련:

#!/bin/bash
# 매분기 첫째 토요일 — staging 호스트에서
set -e

STAGING_PG=/var/lib/pgsql/staging/data
TARGET_TIME="$(date -d '1 hour ago' '+%Y-%m-%d %H:%M:%S')"

# 1. staging 정지·디렉토리 비움
sudo -u postgres pg_ctl -D $STAGING_PG stop -m fast || true
sudo -u postgres rm -rf $STAGING_PG/*

# 2. 최근 백업으로 PITR
sudo -u postgres pgbackrest --stanza=staging \
  --pg1-path=$STAGING_PG --type=time --target="$TARGET_TIME" restore

# 3. 기동
sudo systemctl start postgresql@staging

# 4. 핵심 검증 쿼리
psql -p 5433 -c "SELECT count(*) FROM critical_table;" || {
  echo "FAIL: 검증 쿼리 실패"
  exit 1
}

# 5. 알람 발송 — 성공
curl -X POST https://alert/.../ -d "Recovery drill OK at $(date)"

이렇게 자동화해 둬야 실제 사고 시 절차가 검증된 상태.

복구 시간 측정

매 훈련마다 측정 항목:

단계측정
백업 다운로드MB/s
페이지 풀기MB/s
WAL 재생LSN/s
검증 쿼리ms
총 RTO시간

추세를 그려 배포 클러스터가 커지면 RTO도 커진다는 사실을 인식합니다. RTO 목표를 못 맞추면 증분 백업·standby·다른 전략 검토합니다.

운영 체크리스트

항목빈도
pg_stat_archiver 실패 알람실시간
백업 완료·실패 알람매 백업
verify(pgBackRest)·check(Barman)
자동 PITR 훈련분기
DR 시나리오 시뮬레이션 (사람)반기
보존 정책 점검분기
외부 저장소 무결성매년
복구 절차 문서가 최신화되어 있어야 한다. 클러스터 구성·도구 버전이 바뀌면 옛 절차로 시도하면 실패. 매 분기 훈련 시 절차서도 업데이트.

정리

  • 자주 마주치는 6가지 시나리오: DROP, UPDATE 실수, 클러스터 손실, failover, corruption, 데이터센터 장애
  • 운영의 표준 패턴 = staging PITR → 영향 받은 부분만 export → 운영 patch
  • failover는 standby가 미리 있을 때만 가능
  • 정기 복구 훈련이 진짜 백업의 의미를 만든다
  • 자동화된 자동 PITR + 사람 시뮬레이션 분기·반기 빈도
  • 절차서·도구·구성 모두 훈련 시점에 같이 검증

Part XI 백업과 복구가 끝났습니다. 다음 Part XII에서는 준비된 standby가 있어야 하는 — 복제와 고가용성을 봅니다.