홍라이프 계산기RPO·RTO 백업 주기 점검 쉽게 이해하기 — 개념과 원리
복구 시점 목표(RPO)와 복구 시간 목표(RTO)는 모든 백업·재해 복구 계획의 핵심이 되는 두 숫자입니다. RPO는 업무상 잃어도 되는 데이터의 양을 시간으로 나타낸 것이고, RTO는 서비스가 멈춘 뒤 다시 정상 운영될 때까지 허용되는 시간입니다. 이 점검 도구는 백업 주기와 복원 시간을 두 목표와 비교합니다.
계산 방법
- 최악의 데이터 손실 = 백업 주기입니다. 다음 백업 직전에 장애가 나면 마지막 백업 이후의 모든 변경분을 잃습니다.
- 백업 주기 ≤ 요구 RPO이면 RPO 충족입니다. 아니면 최소 RPO 분마다 백업하라고 안내합니다.
- 복원 시간 ≤ 요구 RTO이면 RTO 충족입니다.
모든 값의 단위는 분입니다.
원리
일정 간격으로 백업하면 백업과 백업 사이에 빈틈이 생깁니다. 장애는 그 빈틈의 어느 순간에나 일어날 수 있어 평균으로는 주기의 절반을 잃지만, 계획은 최악의 경우인 주기 전체를 기준으로 세워야 합니다. 그래서 백업 주기는 RPO보다 길면 안 됩니다. RTO는 데이터가 아니라 시간의 문제로, 장애 순간부터 사용자가 다시 서비스를 쓸 수 있을 때까지를 말합니다. 복원 작업 외에도 장애 감지, 전환 결정, 복원된 시스템 점검에 시간이 듭니다.
예제 풀이
- 입력값은 요구 RPO 60분, 백업 주기 240분, 복원 시간 90분, 요구 RTO 120분입니다.
- 최악의 데이터 손실은 240분, 즉 4시간 분량의 변경분입니다.
- 240 > 60이므로 RPO는 미충족이며, 60분 이하 간격으로 백업해야 합니다.
- 90 ≤ 120이므로 RTO는 충족이고 여유는 30분입니다.
| 백업 간격 (분) | 최악의 데이터 손실 (분) |
|---|---|
| 60 | 60 |
| 120 | 120 |
| 180 | 180 |
| 240 | 240 |
| 300 | 300 |
| 360 | 360 |
| 480 | 480 |
결과 해석
RPO가 0에 가까우면 주기적 백업이 아니라 실시간 복제나 트랜잭션 로그 전송이 필요합니다. RPO가 하루라면 야간 백업으로 충분합니다. RTO는 데이터 전송, 데이터베이스 복구, 애플리케이션 점검까지 포함해 실제 복원 훈련으로 재고, 문제에 대비한 여유를 남겨야 합니다. 결제 시스템과 사내 위키처럼 시스템마다 목표를 다르게 정하는 것이 바람직합니다.
흔한 실수
- RTO를 추정할 때 파일을 되돌리는 시간만 세고 감지와 검증 시간을 빠뜨립니다.
- 모니터링이나 복원 시험 없이 백업이 성공했다고 가정합니다.
- 복제본은 삭제와 손상도 즉시 복사한다는 점을 잊습니다. 복제는 백업이 아닙니다.
자주 묻는 질문
RPO와 RTO는 어떻게 다릅니까?
RPO는 과거를 향해 데이터 손실을 제한하고, RTO는 미래를 향해 중단 시간을 제한합니다.
3-2-1 백업 규칙은 무엇입니까?
데이터를 세 벌 두고, 두 종류의 매체에 저장하며, 한 벌은 외부에 보관하는 원칙입니다.
출처: NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems · ISO 22301, Security and resilience: Business continuity management systems