복구 시간(RTO)과 복구 시점(RPO), 실무에서 어떻게 설계할까?

1. 백업 전략은 복구 목표에서 출발한다

백업을 한다는 것은 단순히 데이터를 저장해두는 것이 아니다.
언제, 어떤 상태로, 얼마나 빨리 복원할 수 있는가를 정의하는 것이 핵심이다.
이 기준이 명확하지 않으면,
백업은 수집만 되고 복구에는 아무런 도움이 되지 않는 경우가 많다.

실무에서는 이 기준을 RTO(복구 시간 목표)와 RPO(복구 시점 목표)라는 수치로 표현한다.
이 두 개념은 복원 전략 전체의 설계 기준이 되며,
백업 주기, 저장소 구조, 자동화 전략까지 모두 여기에 맞춰 조정되어야 한다.

 

2. RTO와 RPO란 무엇인가?

RTO (Recovery Time Objective)

시스템 장애가 발생한 시점부터 복구까지 걸리는 최대 허용 시간
→ "서비스가 언제까지 다시 정상 운영되어야 하는가?"

예: RTO가 2시간이면, 장애 발생 후 2시간 안에 시스템을 복구해야 한다.

RPO (Recovery Point Objective)

복원 가능한 가장 마지막 시점으로부터 현재까지의 데이터 손실 허용 범위
→ "데이터는 어디까지 되살릴 수 있어야 하는가?"

예: RPO가 4시간이면, 복원 시점 기준 최대 4시간 전까지의 데이터는 복원하지 못해도 허용되는 범위다.

 

3. 예시로 이해하는 RTO와 RPO

시스템	RTO	RPO	전략 예시
쇼핑몰 주문 시스템	30분	5분	실시간 복제 + 분산 백업
회계 서버	2시간	1일	주간 이미지 백업 + 일일 DB 덤프
내부 문서 서버	1일	3일	주간 파일 백업 + 월간 아카이브
로그 분석 시스템	48시간	12시간	자동화 없음, 수동 복원

이처럼 시스템의 중요도와 특성에 따라 RTO와 RPO 기준은 달라져야 하며,
그에 따라 백업의 빈도와 방식, 복원 준비 절차도 함께 설계되어야 한다.

 

4. 조직별/업무별 RTO·RPO 설정 기준

• 실시간성 요구가 높은 업무
  → 예: 금융, 커머스, 실시간 API
  → RTO: 10분 이내 / RPO: 1분 이하
  → 고가용성(H/A), 실시간 복제, DR 구축 필요
• 데이터는 중요하지만 복원 속도는 느려도 괜찮은 업무
  → 예: 내부 문서, 연구자료
  → RTO: 12~24시간 / RPO: 6시간 이상
  → 일일 백업 + 오프라인 아카이브 구성 적합
• 법적 보존은 필요하나 운영에 영향이 없는 시스템
  → 예: 감사용 로그, 과거 계약서
  → RTO: 48시간 이상 / RPO: 1~7일
  → 장기 보존 아카이브 설계 + 자동 정리 정책 필요

5. RTO·RPO 기준으로 백업 전략 다시 보기

요소	RTO/RPO 중심 설계
백업 주기	RPO에 따라 조정 (시간 단위 vs 일 단위)
복구 테스트	RTO를 충족하는지 검증하는 수단
저장소 선택	RTO가 짧을수록 복원 속도 빠른 저장소 필요
인프라 이중화	짧은 RTO는 DR 센터 또는 클러스터 필요
스케줄 자동화	RPO가 촘촘할수록 정교한 자동화 필요

 

결론 – 측정하지 않으면 관리할 수 없다

RTO와 RPO는 단순한 개념이 아니라,
복원 중심 백업 전략 전체를 수치화할 수 있는 실무 기준이다.
측정이 가능해야 계획이 가능하고,
계획이 있어야 실제 장애 대응이 가능하다.

당신의 시스템은
몇 분 안에 복구되어야 하고,
몇 시간 전까지의 데이터를 잃을 수 있는가?

이 질문에 스스로 답할 수 있다면,
당신은 이미 복원 전략을 갖춘 백업 설계자다.