본문으로 건너뛰기

1.2 RPO와 RTO 계산

RPO는 허용 가능한 data loss, RTO는 service를 복구해야 하는 시간입니다. “매일 backup”은 schedule일 뿐 RPO를 직접 보장하지 않습니다. WAL archive 지연과 마지막 성공 시각을 포함해야 합니다.

실제 RPO 노출 = 장애 시각 - 마지막으로 안전하게 보존된 변경 시각
실제 RTO = 탐지 + 의사결정 + 준비 + restore + WAL replay + 검증 + traffic 전환

예시

Base backup을 매일 02:00에 만들고 WAL을 1분 이내 off-site로 전송한다면 media가 모두 유효할 때 RPO는 약 1분을 목표로 할 수 있습니다. 그러나 archive가 40분간 실패했다면 실제 RPO 노출은 40분 이상입니다.

RTO는 data size만으로 계산하지 않습니다.

  • Repository에서 restore target까지의 throughput
  • Backup chain과 압축 해제 CPU
  • WAL 양과 replay 속도
  • Infrastructure provisioning
  • Extension과 configuration 복원
  • 검증 query와 application smoke test

측정

복구 훈련마다 단계별 시작과 종료 시각을 기록합니다. 가장 긴 단계와 분산을 보고 RTO budget을 갱신합니다. 예상치가 아니라 반복 측정한 p95가 운영 계획의 입력이 됩니다.

RPO와 RTO는 business owner의 승인 대상입니다. 비용을 줄이기 위해 목표를 완화할 수 있지만, 실제 시스템이 목표보다 느린 상태를 문서 표현으로 숨기면 안 됩니다.