이 글에서 얻는 것

  • 백업/DR/고가용성(HA)의 차이를 구분하고, “무엇이 필요한 상황인지” 판단할 수 있습니다.
  • RPO/RTO를 서비스 요구사항으로 정의하고, 그에 맞는 백업/DR 전략을 선택할 수 있습니다.
  • 스냅샷/증분/PITR 같은 백업 방식의 장단점을 이해하고, 복구(restore) 관점에서 설계할 수 있습니다.
  • “백업은 했는데 복구가 안 된다”를 막기 위한 복구 테스트/드릴 루틴을 만들 수 있습니다.

0) 백업은 ‘파일’이 아니라 ‘복구 능력’이다

백업이 있다고 해서 안전한 게 아닙니다. 복구가 정해진 시간(RTO) 안에, 허용 손실(RPO) 안에서 실제로 성공해야 합니다.

그래서 백업/DR 문서의 핵심은 항상:

  • 무엇을(데이터/설정/키/아티팩트)
  • 어디에(동일 계정? 다른 계정? 다른 리전?)
  • 얼마나 자주(RPO)
  • 얼마나 빨리 복구할지(RTO)

를 명시하는 것입니다.

1) RPO/RTO를 숫자로 정하라

  • RPO(Recovery Point Objective): “얼마나까지 데이터가 사라져도 되는가”
    • 예: RPO 5분이면 “최대 5분치 데이터 손실”을 허용
  • RTO(Recovery Time Objective): “얼마나 빨리 서비스가 복구돼야 하는가”
    • 예: RTO 30분이면 “30분 안에 서비스 정상화”가 목표

RPO/RTO는 기술이 아니라 비즈니스 요구입니다. 이 숫자가 정해져야 전략을 선택할 수 있습니다.

2) 백업 방식 4가지(복구 관점으로 이해)

2-1) 스냅샷(Snapshot)

  • 장점: 빠르고 운영이 쉬움(특히 Managed DB/디스크 스냅샷)
  • 단점: “특정 시점” 단위라 RPO가 촘촘하려면 자주 떠야 함

2-2) 증분/로그 기반(Incremental, WAL/binlog)

  • 장점: RPO를 매우 작게 만들 수 있음
  • 단점: 복구가 복잡(베이스 + 로그 재생), 테스트가 필수

2-3) PITR(Point-in-Time Recovery)

  • 장점: 특정 시점으로 되돌릴 수 있어 운영 사고(삭제/오염)에 강함
  • 단점: 복구 시간이 길어질 수 있고, 설정/보존 정책 관리가 중요

2-4) 논리 백업(Logical dump)

  • 장점: DB 엔진/버전 이동에 유리, 선택 복구 가능
  • 단점: 큰 데이터에서 느리고, 복구 시간이 길어질 수 있음

실무에서는 “스냅샷 + PITR” 같은 조합이 자주 등장합니다.

3) DR(Disaster Recovery) 패턴 4가지

DR은 “리전/AZ 단위로 다 죽는 상황”을 전제로 합니다.

  • Backup & Restore: 평소엔 한 곳에서 운영, 사고 시 백업으로 복구(가장 저렴, RTO 길어질 수 있음)
  • Pilot Light: 최소 핵심만 켜두고(베이스), 사고 시 확장(중간 비용/중간 RTO)
  • Warm Standby: 축소된 형태로 항상 대기, 사고 시 빠르게 확장(비용↑, RTO↓)
  • Active-Active: 두 리전/두 시스템을 동시에 운영(비용/복잡도↑↑, RTO↓)

RTO가 짧아질수록 비용과 복잡도는 급격히 증가합니다.

4) 복구 런북에 반드시 들어가야 하는 것

복구는 “DB만 살린다”로 끝나지 않습니다.

  • 트래픽 전환: DNS/라우팅/로드밸런서
  • 애플리케이션 설정/시크릿: Secret Manager/Vault, 환경 변수, KMS 키 접근
  • 메시지/큐: Kafka/SQS/Redis Streams 같은 비동기 시스템 상태
  • 외부 의존성: 결제/메일/인증 등(재시도 폭탄, 중복 처리)

런북에는 최소한 아래가 있어야 합니다.

  • 복구 시작 조건(누가, 어떤 알람/상황에서)
  • 복구 절차(순서, 명령/콘솔 위치, 책임자)
  • 검증 기준(헬스체크, 핵심 플로우, 데이터 무결성)
  • 사후 조치(원인 분석, 재발 방지)

5) “정기 복구 테스트”가 가장 중요하다

복구는 연습하지 않으면 실전에서 실패합니다.

  • 월/분기 단위로 “실제 복구”를 해본다(테스트 환경이라도)
  • 복구 시간이 RTO를 만족하는지 측정한다
  • 문서/스크립트를 계속 개선한다(드릴을 할수록 빨라짐)

6) 흔한 함정

  • 백업이 같은 계정/같은 리전에만 있다(계정 침해/리전 장애에 취약)
  • 백업은 있지만 “복구 테스트”를 한 번도 안 했다(실전에서 복구 불가)
  • 데이터는 살렸는데 시크릿/키/IaC가 없어 서비스가 안 뜬다
  • 보존 정책이 없어 스냅샷/로그가 끝없이 쌓여 비용이 증가한다

연습(추천)

  • 내 서비스의 RPO/RTO를 “숫자”로 적어보고, 그 값에 맞는 DR 패턴을 선택해보기
  • “DB 스냅샷으로 복구”를 실제로 한 번 해보고(테스트 환경), 걸린 시간을 기록해보기
  • 복구 런북을 1페이지로 작성해보고, 팀원이 보고 따라 할 수 있는지 점검해보기