"백업 매일 돌고 있어요." 모두가 안심했습니다. 그런데 DB가 깨진 날, 막상 복원하려니 백업 파일이 6개월째 손상된 채 쌓여 있었고, 복구 절차를 아는 사람도 없었습니다. 서비스 복구에 사흘. 다른 회사는 리전 전체 장애 때 30분 만에 다른 리전으로 넘어갔습니다 — 차이는 "백업이 있느냐"가 아니라 "얼마 만에, 어느 시점으로 복구되도록 설계했느냐" 였습니다.
- 1RTO(복구 시간)와 RPO(복구 시점)를 구분하고 목표로 설정할 수 있다
- 2'백업이 있다'와 '복구된다'의 차이와 DR 훈련의 필요성을 안다
- 33-2-1 백업 규칙을 클라우드에서 구현하는 법을 안다
- 4DR 전략 스펙트럼(백업복원~핫스탠바이)의 비용 트레이드오프를 판단한다
- 5비즈니스 중요도별로 복구 목표를 차등 적용할 수 있다
목표부터 정한다 — RTO와 RPO
복구는 '얼마 만에'(RTO)와 '어느 시점으로'(RPO)
DR 설계는 기술이 아니라 목표 설정에서 시작합니다.
- RTO(Recovery Time Objective): 장애 후 서비스를 되살리기까지 허용 시간. "2시간 안에 복구"
- RPO(Recovery Point Objective): 복구 시 감수할 데이터 손실 범위. "최근 5분치는 잃어도 됨"
RPO 5분이면 최소 5분마다 백업/복제해야 하고, RTO 30분이면 수시간 걸리는 풀 복원으로는 못 맞춥니다. 이 두 숫자가 백업 주기·DR 전략·비용을 전부 결정합니다.
위 그림처럼 RTO·RPO 둘 다 짧을수록 비용이 급증합니다. 비즈니스 요구사항으로 목표치를 정한 뒤 적합한 전략을 선택합니다.
위 그림처럼 3개 사본, 2가지 매체, 1개 오프사이트를 지키면 단일 위치 재해에서도 데이터를 복구할 수 있습니다.
백업이 '있다' ≠ '복구된다'
가장 흔한 착각이 "백업이 돌고 있으니 안전하다"입니다. 백업이 있어도:
- 파일이 손상됐거나 암호화 키를 잃어 못 읽을 수 있고
- 복구 절차를 아무도 해본 적 없어 사고 때 헤매고
- 대용량 복구가 RTO를 초과할 수 있습니다
'백업 성공 로그'는 복구를 보장하지 않습니다. 정기적으로 백업에서 실제 복원해보는 DR 훈련(game day) 이 유일한 진짜 검증입니다(관리형 데이터베이스(RDS)의 PITR 복원 연습).
3-2-1 규칙 — 분리된 사본으로 살아남기
사본 3개 / 서로 다른 2개 위치 / 그중 1개는 오프사이트(다른 리전·계정). 한 위치가 통째로 날아가도(리전 장애), 실수로 지워도, 랜섬웨어로 암호화돼도 분리된 사본이 살아남습니다.
클라우드 구현: 교차 리전 복제 + 별도 계정 보관 + 불변(immutable) 스토리지(쓰기 후 변경·삭제 방지). 백업 계정을 분리하면 운영 계정이 침해돼도 백업은 지켜집니다(관측과 거버넌스의 멀티계정·가드레일).
'백업 잡이 켜져 있다'가 아니라 '최근 복구 지점이 실제로 생성됐는지'를 봅니다.
aws backup list-recovery-points-by-backup-vault --backup-vault-name prod-vault \
--query "RecoveryPoints[0:3].{Created:CreationDate,Status:Status,Size:BackupSizeInBytes}" --output table
+----------------------+-----------+-------------+
| 2026-06-16T02:00Z | COMPLETED| 53687091200|
| 2026-06-15T02:00Z | COMPLETED| 53201000000|
+----------------------+-----------+-------------+
aws backup list-recovery-points-by-backup-vault오프사이트 사본이 실제로 있는지 — 오프사이트가 없으면 리전 장애에 속수무책입니다.
aws backup list-copy-jobs --by-state COMPLETED \
--query "CopyJobs[0:3].{Dest:DestinationBackupVaultArn,State:State}" --output table
+--------------------------------------------------+-----------+
| arn:aws:backup:ap-northeast-1:...:vault/dr-vault | COMPLETED| ← 도쿄로 복사됨
+--------------------------------------------------+-----------+
aws backup ...- 최근 RecoveryPoint의 CreationDate가 RPO 목표보다 오래됐는지 — 예: RPO 24h인데 마지막 백업이 3일 전이면 백업 잡 실패. 즉시 원인 점검
- Status가 COMPLETED가 아닌(FAILED/PARTIAL) 복구 지점 — 백업이 실패 중. '성공 로그'만 믿지 말고 상태 직접 확인
- 교차 리전/계정 복사(copy-job)가 없는 핵심 데이터 — 오프사이트 사본 부재. 리전 장애·랜섬·실수삭제에 취약(3-2-1의 1 누락)
- 마지막 DR 복구 훈련 일자 — 한 번도 복원해본 적 없으면 RTO는 '추정'일 뿐. 정기 game day 일정 수립
상황: 백업은 있는데 복구가 RTO를 크게 초과.
원인: ① 대용량 데이터를 콜드/아카이브 스토리지에서 꺼내는 데 시간(검색 지연), ② 복원 후 인덱스 재생성·캐시 워밍 등 후속 작업 미고려, ③ 복구 절차가 수동·미문서화라 단계마다 지체, ④ RTO를 측정 없이 '희망'으로 잡음.
진단: 백업 스토리지 클래스(꺼내는 속도) 확인 → 실제 복원 시간을 game day로 측정 → 복원 후 정상화까지 전체 시간 측정.
해결: RTO가 빡빡하면 백업·복원 대신 웜/핫 스탠바이로 전략 격상(클라우드 비용 최적화 비용 트레이드오프 감수). 자주 복구하는 데이터는 즉시 접근 가능한 스토리지 클래스에. 복구 절차를 자동화(IaC와 Terraform)·문서화(runbook)하고 정기 훈련으로 실측 RTO를 확보. RTO는 '재본 적 있는' 숫자여야 합니다.
면접·감사 단골: "RTO/RPO가 어떻게 되나요?"에 숫자로 답하고 그 근거(백업 주기·DR 전략)를 말할 수 있어야 합니다. "백업해요"만으로는 부족 — "RPO 15분(15분마다 복제), RTO 1시간(웜 스탠바이), 분기마다 복구 훈련"처럼 목표·수단·검증이 세트입니다.
실무 핵심: ① 모든 시스템에 같은 DR을 적용하지 말고 비즈니스 중요도별 차등(결제=핫스탠바이, 내부도구=백업복원), ② 백업 계정·리전 분리로 침해·삭제·랜섬 격리, ③ '백업 있음'이 아니라 '복구 검증됨'을 KPI로. 백업 비용은 보험이지만, 복구 안 되는 백업은 비싼 착각입니다. 이 주제는 관리형 데이터베이스(RDS)·관측과 거버넌스·클라우드 비용 최적화와 한 묶음으로 운영됩니다.
다음 단계로는 이 복원력을 코드로 선언·자동화하는 IaC와 Terraform, 백업·복구 상태를 관측·알람하는 관측과 거버넌스로 이어집니다.