재해 복구(DR) 설계는 두 숫자에서 시작한다. RPO(Recovery Point Objective)는 "얼마만큼의 데이터를 잃어도 되는가", RTO(Recovery Time Objective)는 "얼마 만에 복구해야 하는가"다. 이 둘이 정해지지 않으면 나머지 설계는 전부 감으로 하게 된다.
그리고 반드시 구분해야 할 것이 하나 더 있다. 복제는 가용성 장치이고 백업은 복구 장치다. 복제는 잘못된 삭제도 그대로 복제한다. 둘을 같은 것으로 취급하는 순간 방어선이 하나로 줄어든다.
백업 이야기를 할 때 나는 항상 같은 질문부터 한다. "마지막으로 복구를 해 본 게 언제인가요?" 대부분 대답이 흐려진다. 백업 작업이 성공했다는 로그는 매일 쌓이는데, 그 백업에서 실제로 서비스를 되살려 본 적은 없는 경우가 많다. 검증되지 않은 백업은 백업이 아니라 희망이다.
RPO·RTO를 정하는 법
전사에 하나의 값을 정하려 하면 합의가 안 된다. 데이터와 시스템을 등급으로 나눠 각각 정하는 게 현실적이다.
| 등급 | 예시 | RPO | RTO |
|---|---|---|---|
| 치명 | 결제·주문 원장, 회원 인증 | 수 분 이내 | 1시간 이내 |
| 중요 | 서비스 콘텐츠, 설정, 이력 | 1시간 | 수 시간 |
| 일반 | 로그, 분석 데이터 | 1일 | 1일 |
| 재생성 가능 | 캐시, 썸네일, 파생 데이터 | 해당 없음 | 재생성 시간 |
복제와 백업의 차이
| 수단 | 막아 주는 것 | 막지 못하는 것 |
|---|---|---|
| 같은 리전 다중 AZ 복제 | 단일 데이터센터 장애 | 리전 단위 사건, 논리적 삭제 |
| 크로스 리전 복제 | 리전 단위 사건 | 실수·악의적 삭제(그대로 복제됨) |
| 스냅샷 | 실수 삭제, 인스턴스 손실 | 스냅샷이 같은 계정·리전에만 있으면 함께 잃음 |
| 불변(immutable) 백업 | 랜섬웨어, 계정 탈취 후 삭제 | 보관 기간 이후의 손실 |
| 오프라인·별도 계정 보관 | 광범위 침해 | 복구 절차를 모를 때 |
마지막 줄이 농담이 아니다. 실제 사고에서 가장 흔한 실패는 백업이 없어서가 아니라, 복구 절차를 아는 사람이 없어서 시간이 흘러가는 경우다.
3-2-1 규칙의 현대적 해석
고전적인 3-2-1 규칙은 "복사본 3개, 매체 2종류, 오프사이트 1개"다. 클라우드 시대에는 이렇게 읽는 게 실용적이다.
# 크로스 계정·크로스 리전 백업의 최소 형태 (개념)
# 1) 스냅샷 생성 (운영 계정)
aws rds create-db-snapshot --db-instance-identifier prod \
--db-snapshot-identifier prod-$(date +%Y%m%d)
# 2) 다른 리전으로 복사
aws rds copy-db-snapshot \
--source-db-snapshot-identifier arn:aws:rds:ap-northeast-2:111:snapshot:prod-20260916 \
--target-db-snapshot-identifier prod-20260916-dr \
--source-region ap-northeast-2 --region ap-southeast-1
# 3) 별도 백업 계정으로 공유 (운영 계정이 털려도 남도록)
aws rds modify-db-snapshot-attribute \
--db-snapshot-identifier prod-20260916-dr \
--attribute-name restore --values-to-add 222222222222
# 4) 객체 스토리지는 버전 관리 + 객체 잠금(보존 모드)으로 불변성 확보데이터만으로는 못 뜬다
복구 계획에서 자주 빠지는 것들이 있다. 데이터베이스를 되살려도 서비스는 안 뜬다.
복구 리허설 — 실제로 하는 법
리허설은 거창할 필요 없다. 핵심은 끝까지 가 보는 것이다. 스냅샷에서 인스턴스를 띄우는 것까지가 아니라, 애플리케이션을 연결해 쿼리가 나오는 것까지.
첫 리허설에서는 대개 문서가 틀렸다는 걸 발견한다. 그게 리허설의 목적이다. 사고 당일에 발견하는 것보다 백 배 낫다.
실전에서 자주 나오는 질문들
- 치명 데이터만 크로스 리전 — 전부 하면 비용이 감당 안 된다
- 대기 환경은 축소 구성으로 — 필요 시 확장
- 로그·분석 데이터는 RPO를 길게
- 파생 데이터는 재생성으로 대체
- 복구 절차 문서화
- 정기 복구 리허설
- 백업의 권한 경계 분리
- 복구 책임자 지정(휴가·퇴사 대비 2인 이상)
자주 묻는 질문
RPO와 RTO는 어떻게 정하나요?
데이터와 시스템을 등급으로 나눠 각각 정하는 것이 현실적입니다. 결제·인증 같은 치명 등급은 분 단위 RPO와 시간 단위 RTO가 필요하고, 로그나 분석 데이터는 훨씬 느슨해도 됩니다. 전사 단일 값을 정하려 하면 비용이 감당되지 않습니다.
멀티 AZ 구성이면 백업은 필요 없나요?
필요합니다. 복제는 가용성을 위한 장치라 잘못된 삭제나 데이터 손상도 그대로 복제합니다. 또한 리전 단위 사건에는 같은 리전의 복제본이 함께 영향을 받으므로, 별도 백업과 다른 실패 도메인이 필요합니다.
백업을 어디에 두어야 안전한가요?
서로 다른 실패 도메인(다른 리전, 가능하면 다른 계정)에 두고, 최소 하나는 권한 경계 밖에 불변 형태로 보관하세요. 계정이 탈취돼도 지울 수 없어야 랜섬웨어와 내부자 위험에 대응할 수 있습니다.
복구 리허설은 얼마나 자주 해야 하나요?
핵심 시스템은 분기 1회를 권합니다. 범위를 좁혀 한 시스템씩 돌아가며 수행하고, 소요 시간을 측정해 RTO 수치를 갱신하세요. 리허설에서 문서의 오류를 발견하는 것이 가장 큰 수확입니다.
데이터 외에 무엇을 복구 계획에 넣어야 하나요?
인프라 정의(IaC), 시크릿과 인증서, DNS 설정, 컨테이너 이미지, 외부 연동 설정, 그리고 운영 문서입니다. 특히 장애 대응 문서가 복구 대상 시스템 안에 있으면 사고 당시에 열 수 없으니 별도 위치에 두세요.
비용을 줄이면서 DR을 갖추려면요?
치명 등급 데이터만 크로스 리전으로 보호하고, 대기 환경은 축소 구성으로 두었다가 필요 시 확장하는 방식이 효율적입니다. 파생 데이터는 백업 대신 재생성으로 대체하고, 어떤 데이터가 소실 대상인지 문서로 남겨 승인받아 두세요.
댓글 0