이 노트는 백업 파일의 존재를 복구 가능성의 증거로 오해하지 않도록, 복구 지점·복구 시간·서비스 간 사실의 일치·외부 효과의 격리를 한 흐름으로 묶습니다. 먼저 RPO와 RTO의 시작·종료 경계를 고정하고, 각 서비스의 snapshot과 로그 위치를 안정된 업무 ID로 대사한 다음, 복원 환경을 안전하게 검증한 뒤에만 traffic을 허용하는 순서를 설명합니다.
백업 성공과 실제 복구 가능성
backup bytes가 있어도 암호화 key·권한·호환 DB version·WAL 일부가 없으면 복원하지 못할 수 있습니다. RPO는 허용 데이터 유실 범위, RTO는 정의된 시작점부터 서비스 재개까지 허용 시간입니다. 실제 복원된 최신 유효 변경과 장애 시각을 대조해야 RPO를 알 수 있습니다.
매일 전체 backup만으로 RPO 1시간을 약속할 수 없습니다. 증분/WAL 보관·전송 간격·손상·마지막 유효 위치를 확인합니다. replica는 빠른 failover에 도움되지만 잘못된 삭제도 복제되므로 논리 오류 전 시점 복구를 대체하지 않습니다.
RTO 구간과 복사 외 복구 작업
| 구간 | 포함할 작업 |
|---|---|
| 탐지·결정 | 장애 확인·호출·복구 판단 |
| 권한·key | 원본 계정/지역 불능 때 접근 |
| 환경 | infra·DB version·설정·network |
| 복원 | full·증분·WAL·index·검증 |
| 서비스 재개 | DNS·traffic·cache·핵심 쓰기 |
| 후속 대사 | 손상/불확정 데이터 처리 상태 별도 |
측정 시작을 key 승인 뒤로 미루면 오래 걸린 승인 시간을 숨깁니다. 조직이 정의한 장애/복구 개시 기준을 고정하고 실제 구간별 시간을 남깁니다. backup과 key의 장애·삭제 권한을 분리해 원본 계정 상실이 모두를 함께 없애지 않게 합니다.
서비스별 동일 timestamp와 원자 Cut의 보장 한계
주문 backup이 결제 요청 전 시점이고 결제 backup이 결제 성공 후 시점이면, 두 백업에 기록된 사실의 순서가 서로 맞지 않을 수 있습니다. 따라서 두 시스템의 “둘 다 12시” timestamp만 맞추어서는 인과가 일치했다고 볼 수 없습니다. 가능하면 조정된 snapshot·로그 위치·처리 watermark 중 실제 계약이 있는 기준을 선택하고, 복구 뒤 안정 주문/event ID로 주문·결제·재고·외부 provider의 상태를 대사합니다.
그림을 글로 읽기
- 주문 snapshot·log 위치
- 결제 snapshot·log 위치
- 주문 ID·event ID·외부 원장 대사
- 참조·잔액·인가·핵심 쓰기 검증
- 재개 기준 충족 뒤 traffic 허용
- 주문 snapshot·log 위치 → 주문 ID·event ID·외부 원장 대사: 복구한 사실
- 결제 snapshot·log 위치 → 주문 ID·event ID·외부 원장 대사: 복구한 사실
- 주문 ID·event ID·외부 원장 대사 → 참조·잔액·인가·핵심 쓰기 검증: 누락·중복·불확정 분리
- 참조·잔액·인가·핵심 쓰기 검증 → 재개 기준 충족 뒤 traffic 허용: 실제 서비스 기준
없는 결제를 새로 실행하거나 고아 주문을 임의 삭제하지 않습니다. 이미 외부에서 성공했는지 조회하고 보정·미확정·수동 확인을 구분합니다. 사용자 서비스 재개와 모든 후속 대사 완료를 별도로 보고합니다.
Restore 환경의 옛 Mail·Outbox 외부 전송 차단
실제 backup에는 개인정보·token·과거 outbox·scheduler state가 있으며, 복원하면 이런 데이터가 함께 읽힐 수 있습니다. 그래서 복원 작업을 시작하기 전부터 운영 endpoint·자격·egress를 차단하고, 자동 consumer와 scheduler가 시작되지 않도록 합니다. 외부로 보내는 대신 허용한 합성 sink로 전환한 뒤 필요한 읽기·제한된 쓰기·event 경로를 확인하며, log 수집도 개인정보를 복제하는 경로로 따로 다룹니다.
비식별 합성 데이터 훈련은 절차 검증에 유용하지만 실제 backup의 읽기 가능성·key 접근·무결성을 증명하지는 않습니다. 실제 backup 검사는 통제된 접근·암호화·보관·삭제 환경에서 필요한 범위로 수행해야 합니다.
복구 데이터와 사용자 흐름의 통합 검증
건수·checksum뿐 아니라 주문-결제 참조·잔액 원장·현재 권한·새 주문 쓰기·event 발행·복구 후 retry를 확인합니다. 논리 삭제·지역 불능·key 지연·WAL 손상·서로 다른 cut·옛 outbox를 나눠 훈련하고 실패 단계와 실제 RPO/RTO를 기록합니다. 이 노트는 복구 설계이며 실제 운영 backup을 복원한 결과는 아닙니다.
재현 연습에서는 합성 주문 하나를 주문 snapshot에는 존재하지만 결제 snapshot에는 없는 상태, 그리고 외부 결제 원장에는 성공으로 남은 상태로 구성합니다. 예상 결과는 두 시스템의 동일한 벽시각을 정답으로 채택하지 않고, 주문 ID·event ID·외부 원장 조회를 통해 미확정 상태로 분리하는 것입니다. 복구 환경에서 scheduler를 켜기 전 외부 endpoint 차단이 유지되는지도 확인해야 하며, 이 연습은 실제 key 복구나 운영 backup 무결성을 증명하지 않는다는 한계를 기록합니다.