빨리 복구했지만 주문 한 시간치가 없었다
가상 이야기 · 핵심노트 기반
핵심노트 개념: RTO와 RPO — 복구 시간과 손실 목표를 검증한다
이 글에서 배우는 교훈
RTO는 서비스를 복구하는 시간, RPO는 복구해야 할 데이터의 시점을 정하는 서로 다른 목표입니다.
핵심노트를 바탕으로 만든 가상 이야기입니다. 실제 사건이나 검증된 성과가 아닙니다.
근거: RTO와 RPO — 복구 시간과 손실 목표를 검증한다 · 핵심노트 8
구체적으로는 40분 만에 복구했어도 한 시간 전 주문까지만 남아 RPO를 어겼으므로 복구 시간과 마지막 거래 시점을 별도로 검사했습니다.
관련 교재 내용
시스템아키텍처 이해와 활용 · VIII. 장애 대응 · RTO와 RPO
RTO는 허용하는 복구 시간, RPO는 복구해야 할 데이터의 시점에 관한 목표입니다. 재난복구는 시스템을 다시 동작시켜 업무의 중단 영향을 줄이는 일입니다.
이 사례에 적용한 내용: 40분 만에 복구했어도 한 시간 전 주문까지만 남아 RPO를 어겼으므로 복구 시간과 마지막 거래 시점을 별도로 검사했습니다.
교재 원리의 실무 적용 · 교재 원문 인용이 아닌 자체 설명입니다.
본문
주문 시스템의 목표는 RTO 1시간, RPO 10분이었습니다. 오전 10시 장애를 가정한 복구 시험에서 10시 40분에 서비스를 다시 켰습니다. 팀은 목표를 지켰다고 생각했지만 복원된 마지막 주문은 오전 9시 자료였습니다. 40분 안에 켰어도 9시 50분까지의 주문을 복구해야 한다는 목표는 지키지 못했습니다.
운영자는 서비스를 사용할 수 있을 때까지의 시간과 복원된 마지막 거래 시점을 따로 기록했습니다. 백업뿐 아니라 이후 변경을 복원할 로그의 보관·반영 방법을 점검하고, 설정과 필요한 키도 함께 복원했습니다. 다시 시험할 때는 주문 조회·접수 성공과 복원된 거래 범위를 모두 확인했습니다.
결론
복구가 빨랐다는 사실만으로 데이터 손실이 작았다고 말할 수 없습니다. RTO와 RPO를 나눠 검증해야 장비·설정 준비와 데이터 보호 중 무엇을 보완할지 알 수 있습니다.