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의 승인 대상입니다. 비용을 줄이기 위해 목표를 완화할 수 있지만, 실제 시스템이 목표보다 느린 상태를 문서 표현으로 숨기면 안 됩니다.