회복 테스트로 백업과 복구 절차의 실효성 검증하기
회복 테스트의 범위와 RTO·RPO 검증 기준, PITR·리전 DR·랜섬웨어 대응을 포함한 복구 절차 검증 방법을 정리합니다.
2026-08-14 · 최초 발행 2025-12-17
백업이 복구 가능성을 뜻하지는 않는다
회복 테스트(Recovery Test)는 장애나 재해가 발생한 뒤, 정해 둔 목표 시점과 시간 안에 시스템을 되살릴 수 있는지 확인하는 비기능 테스트다. 백업 파일의 존재만 확인하는 데 그치지 않고, RTO와 RPO 목표를 만족하는지, 데이터가 온전한지, 운영 절차가 실제로 실행 가능한지를 검증한다.
검증 범위는 컴퓨트·스토리지·네트워크 같은 인프라부터 데이터베이스와 메시지 브로커, 애플리케이션 계층, 외부 의존성, 관측·모니터링 체계까지 이어진다. 대규모 분산 시스템이나 클라우드와 온프레미스를 함께 쓰는 환경에서는 재해복구 체계의 신뢰성을 확인하는 수단이 된다.
RTO(Recovery Time Objective)는 서비스 중단을 허용할 수 있는 시간의 한계이고, RPO(Recovery Point Objective)는 허용 가능한 데이터 손실 시점의 한계다. 회복 테스트는 이 두 목표가 문서상의 선언이 아니라 실제 절차로 달성되는지 검증한다.
검증 대상은 백업 파일보다 넓다
테스트 시나리오에는 계획된 정지와 비계획 정지, 단일 컴포넌트 장애와 리전 장애, 데이터 손상·삭제, 설정 오류를 포함할 수 있다. 정상 케이스와 실패 케이스를 함께 설계해야 탐지와 완화 절차도 확인할 수 있다.
백업 체계에서는 전체·증분·스냅샷·로그(redo/WAL) 기반 백업 체인의 유효성과 보존 정책을 점검한다. 암호화, 무결성 체크섬, 불변 저장소(Immutable/Object Lock)의 적용 여부도 검토 대상이다.
성공 기준에는 RTO/RPO 충족 여부, 데이터 무결성·일관성, 애플리케이션 기능이 포함된다. 경보 품질(MTTD), 복구 시간(MTTR), 백업 손상률, 실패 재시도 성공률도 측정할 수 있다. IaC와 파이프라인으로 테스트 환경을 자동 프로비저닝하고 복구 절차를 스크립트화하면 반복성을 높일 수 있으며, 혼돈 엔지니어링 도구를 통한 실패 주입과 정기 실행도 가능해진다.
권한 최소화, 키 관리(KMS), 감사 로깅, 운영·보안·검증 역할 분리도 복구 절차에 포함해야 한다. 전자금융이나 ISO 27001 같은 규제 준수 기준에 맞춰 증적을 생성하고 보관하는 일 역시 회복 테스트의 일부다.
실패를 가정하고 복구 경로를 따라간다
먼저 서비스별 RTO/RPO와 성공·실패 판정 기준을 정한다. 데이터 계층과 상태 저장 컴포넌트, 메일·결제·3rd-party API 같은 외부 종속성을 식별하고, 테스트 전용 네트워크·계정·키·스토리지를 분리한 뒤 비용과 시간 한도를 둔다.
실패 주입 단계에서는 프로세스를 강제 종료하거나 디스크 I/O 오류를 시뮬레이션하고 리전 장애를 가정할 수 있다. 이어 최신 백업 여부, 체인 연결 상태, 복구 미디어의 해시·체크섬 무결성을 확인한다.
복구할 때는 전체·증분·스냅샷 중 사용할 미디어를 고르고, 필요하면 로그 재생(PITR) 전략을 적용한다. 일반적인 복구 순서는 데이터베이스, 메시지 브로커, 캐시, 애플리케이션, 엣지·DNS다. 재생 중에는 쓰기를 차단하고 일관성 포인트를 확보하며 캐시 콜드스타트 전략을 적용한다.
복구 후에는 체크섬, 레코드 카운트, 참조 무결성, 정합성 쿼리로 데이터를 검증한다. 합성 트랜잭션, 회귀 테스트 스위트, 도메인 중요 시나리오로 애플리케이션도 확인한다. 로그·메트릭·트레이스를 검토하며 경보의 민감도와 오탐·미탐을 분석한 뒤, RTO/RPO 달성 여부와 실패 원인, 개선안을 결과 보고에 남긴다. 런북은 이 결과를 바탕으로 표준화하고 자동화 스크립트와 교육·훈련 계획을 보강한다.
복구 과정에서 확인할 분기
복구 시나리오가 다루는 대상
데이터베이스에서는 PostgreSQL/MySQL의 아카이브 로그를 이용해 시점복구를 시험할 수 있다. 특정 트랜잭션 직전까지 복구한 뒤 외래키·고유키·합계값의 정합성을 확인한다.
쿠버네티스 애플리케이션은 Velero 등으로 네임스페이스와 PVC 스냅샷을 복원하고, 시크릿·컨피그맵 키가 회복되는지 본다. 롤링 재배포와 서비스 엔드포인트 전환도 검증 범위다.
랜섬웨어 대응 드릴에서는 불변 스토리지(Object Lock, WORM)의 클린 백업을 사용할 수 있는지 확인한다. 감염 지점을 식별하고 감염 전 시점으로 복구하며 네트워크 분리 절차를 점검한다.
리전 DR 전환은 액티브-패시브 구조에서 DNS·글로벌 로드밸런서 전환과 데이터 복제 지연의 영향을 검증하는 시나리오다. 재가동 후 역동기화(back-sync)와 원복(run-back) 절차도 포함된다. 메시지 큐는 Dead-letter 큐 재주입, idempotent 소비자, 중복 처리 방지 여부를 확인할 수 있다.
복구 방식마다 남는 운영 조건
| 전략 | 성능(복구시간) | 일관성 | 안정성 | 운영 편의 | 비고 |
|---|---|---|---|---|---|
| 전체 백업 복구 | 중 | 높음 | 높음 | 중 | 단순하지만 저장공간·시간 부담 큼 |
| 증분 체인 복구 | 중~장 | 중~높음 | 중 | 중 | 체인 단절 위험, 검증 자동화 필수 |
| 스냅샷 기반(EBS/ZFS/LVM) | 높음 | 중~높음 | 높음 | 높음 | I/O 일시정지·충돌 고려 필요 |
| 로그 기반 PITR(WAL/Redo) | 중 | 높음 | 중~높음 | 중 | 목표 시점 정밀 복구 가능 |
| 스탠바이 전환(스트리밍 복제) | 매우 높음 | 중~높음 | 중 | 높음 | 장애 전파·논리 손상 동기화 위험 |
PostgreSQL PITR로 복구 시점을 검증하는 방법
전제조건은 PostgreSQL 14 이상, Linux, 테스트 전용 호스트다. archive_mode=on과 archive_command를 설정한다. 예시는 cp %p /pg/wal-archive/%f다.
# 1) 백업/아카이브 준비
psql -c "CREATE TABLE t(id int primary key, v text);"
psql -c "INSERT INTO t VALUES (1,'before');"
TGT_TIME=$(date -u +"%Y-%m-%d %H:%M:%S UTC")
pg_basebackup -D /pg/base-$(date +%s) -Ft -X stream -z -v -P
# 2) 변경 작업(복구 대상에서 제외될 데이터)
psql -c "INSERT INTO t VALUES (2,'after');"
# 3) 장애 가정 및 데이터 디렉터리 교체(테스트 환경 한정)
pg_ctl -D $PGDATA -m immediate stop
mv $PGDATA ${PGDATA}.bak
mkdir -p $PGDATA && tar -xf /pg/base-*/base.tar.gz -C $PGDATA
# 4) 복구 설정
cat >> $PGDATA/postgresql.conf <<EOF
restore_command = 'cp /pg/wal-archive/%f %p'
recovery_target_time = '${TGT_TIME}'
EOF
touch $PGDATA/recovery.signal
chown -R postgres:postgres $PGDATA
# 5) 기동 및 검증
pg_ctl -D $PGDATA start
psql -c "TABLE t;" # id=1만 존재해야 함검증 시에는 TGT_TIME 이전 트랜잭션만 존재하는지 확인한다. 인덱스 재빌드·확장 통계·시퀀스 값의 정합성도 점검한다.
보안과 자동화 사이의 선택
저장소와 전송을 암호화하고 키를 분리 보관하며 Object Lock을 적용하는 방식은 복구 체계의 보안을 강화한다. 대신 복구 속도와 운영 복잡도가 증가할 수 있다.
프로덕션과 분리된 계정·네트워크·키를 사용하고 샌드박스 비용 상한을 두면 테스트 격리를 강화할 수 있다. 완전히 격리된 환경에서는 실제 트래픽 패턴을 재현하기 어려울 수 있다.
IaC와 파이프라인으로 원클릭 복구와 정기 실행을 구성하면 반복 실행이 쉬워진다. 초기 구축과 유지보수 비용은 늘어난다. 데이터 일관성을 위해 애플리케이션 수준의 idempotency, 큐 재처리, 사가 보상 트랜잭션을 적용할 수도 있지만 개발 복잡도와 성능 오버헤드가 발생한다.
반복 검증이 남기는 운영 효과
회복 테스트는 RTO/RPO 달성률을 높이고 MTTR을 30~70% 단축하며, 백업 손상을 사전에 발견하는 비율을 높일 수 있다. 감사 대응 시간은 50% 이상 단축되고 인시던트 재발 방지율도 향상될 수 있다.
무엇보다 복구 절차의 신뢰성을 높이고 팀의 대응 역량을 강화한다. 문서화와 런북 표준화는 조직 학습과 지식 축적을 가속하며, 경영진과 감사기관의 신뢰를 뒷받침한다.