복구 훈련 기록으로 RPO·RTO 를 재고 사후 분석을 쓴다

목표

백업 사본 목록에서 3-2-1 위반을 찾고, 백업 작업 기록과 장애 기록으로 실제 데이터 손실 시간(RPO)과 복구 시간(RTO)을 재서 목표와 비교하고, 복원본을 목록과 대조한 뒤, 사람을 탓하지 않는 사후 분석과 담당·기한이 있는 개선 조치를 씁니다.

왜 중요한가

"RPO 1시간, RTO 90분" 은 문서의 목표일 뿐입니다. 백업이 조용히 실패하고 있었다면 실제 손실은 몇 배가 되고, 복원 명령 시간만 재면 탐지와 판단에 든 시간이 빠집니다. 복구 훈련은 그 차이를 숫자로 드러내는 일이고, 사후 분석은 그 숫자를 다음 개선으로 바꾸는 문서입니다. 누가 잘못했는지를 적기 시작하면 사실이 숨고 조건은 그대로 남습니다.

재료는 /opt/lab/capacity/dr/ 에 있고, 채점기는 기대값을 원본 재료에서 계산합니다.

단계

1. /opt/lab/capacity/dr/ 의 내용 전부를 /root/dr/ 로 복사하세요.
2. 3-2-1 규칙(사본 3개·매체 2종·장소 2곳)을 어기는 데이터를 /root/dr/01-321.txt 에 violations= 로 적으세요.
3. /root/dr/02-rpo.txt 에 last_good=, loss_min=, meets_rpo= 를 적으세요.
4. /root/dr/03-rto.txt 에 rto_min=, meets_rto=, longest_phase= 를 적으세요.
5. 복원본을 MANIFEST.sha256 과 대조해 /root/dr/04-verify.txt 에 missing=, mismatch= 를 적으세요.
6. /root/dr/postmortem.md 에 요약·영향·타임라인·근본 원인·개선 조치 다섯 절을 쓰세요(타임라인 여섯 시각, 영향의 두 숫자, 담당자 이름 없는 근본 원인).
7. 개선 조치를 세 개 이상, 각각 담당: 과 기한: YYYY-MM-DD 를 붙여 적되 탐지·백업·3-2-1 빈틈을 모두 다루세요.

참고

• 시각 계산: datetime.strptime(s, '%Y-%m-%d %H:%M'), 두 시각의 차 .total_seconds() // 60.
• 복원 검증: cd restored && sha256sum -c MANIFEST.sha256.
• 흔한 실수 1: 실패한 백업을 last_good 으로 세는 경우 — 되살릴 수 없는 지점입니다.
• 흔한 실수 2: RTO 를 복원 시작부터 세는 경우 — 사용자는 장애 순간부터 멈춰 있었습니다.

재료 복사

/opt/lab/capacity/dr/ 의 내용 전부(restored/ 디렉터리 포함)를 /root/dr/ 로 복사하세요.

디렉터리째 옮기려면 cp -r 을 씁니다. incident.log 와 backup_jobs.log 부터 읽어 보세요.

3-2-1 규칙 점검

backups.json 의 데이터마다 사본 목록(원본 포함)을 보고, 사본 3개 이상 · 매체(media) 2종 이상 · 장소(site) 2곳 이상 가운데 하나라도 어기는 데이터를 /root/dr/01-321.txt 에 violations=<이름들, 쉼표로> 로 적으세요.

데이터마다 len(사본), 서로 다른 media 수, 서로 다른 site 수를 셉니다. 같은 장소의 스냅숏 셋은 사본이 셋이어도 규칙을 어깁니다.

실제 데이터 손실 시간

incident.log 의 failure 시각과 backup_jobs.log 로 /root/dr/02-rpo.txt 에 세 줄을 적으세요: last_good=<장애 이전에 OK 로 끝난 마지막 백업, YYYY-MM-DD HH:MM>, loss_min=<장애 시각 − last_good, 분>, meets_rpo=<targets.env 의 RPO_MIN 이하면 yes, 아니면 no>.

마지막 백업이 아니라 마지막으로 성공한 백업입니다. FAILED 로 끝난 작업은 되살릴 지점이 되지 못합니다.

실제 복구 시간과 가장 긴 구간

incident.log 로 /root/dr/03-rto.txt 에 세 줄을 적으세요: rto_min=<failure 부터 verified 까지, 분>, meets_rto=<RTO_MIN 이하면 yes, 아니면 no>, longest_phase=<detect·decide·prepare·restore·verify 가운데 가장 긴 구간>. 구간은 차례로 failure→detected, detected→declared, declared→restore_start, restore_start→restore_end, restore_end→verified 입니다.

복원 명령이 돈 시간만이 아니라 장애가 시작된 순간부터 셉니다. 사용자에게 서비스는 그때부터 멈춰 있었습니다.

복원본 검증

/root/dr/restored/ 의 파일을 MANIFEST.sha256 과 대조해 /root/dr/04-verify.txt 에 두 줄을 적으세요: missing=<목록에는 있는데 복원본에 없는 파일, 쉼표로>, mismatch=<있지만 해시가 다른 파일, 쉼표로>.

restored 디렉터리 안에서 sha256sum -c MANIFEST.sha256 을 돌리면 파일마다 OK·FAILED·없음이 나옵니다. 오류로 끝나도 출력은 끝까지 읽으세요.

사람을 탓하지 않는 사후 분석

/root/dr/postmortem.md 를 쓰세요. ## 요약, ## 영향, ## 타임라인, ## 근본 원인, ## 개선 조치 다섯 절이 있어야 합니다. 타임라인에는 incident.log 의 여섯 시각을 모두 옮기고, 영향에는 3·4단계에서 잰 실제 손실 분과 복구 분을 숫자로 적으세요. 근본 원인에는 담당자 계정 이름을 쓰지 말고, 장애를 일으킨 조건과 복구를 늦춘 조건을 적으세요.

누가 실수했는지가 아니라, 그 사람이 그렇게 할 수밖에 없게 만든 조건(경보가 없었다, 여유를 아무도 보지 않았다)을 적습니다. 개선 조치 절은 7단계에서 채워도 되지만 절 제목은 지금 있어야 합니다.

담당과 기한이 있는 개선 조치

postmortem.md 의 ## 개선 조치 절에 - 로 시작하는 항목을 세 개 이상 적으세요. 항목마다 담당: <누구> 와 기한: YYYY-MM-DD 가 있어야 하고, 이 사건이 드러낸 세 빈틈 — 탐지(경보), 백업(실패가 조용했다), 3-2-1(2단계에서 찾은 위반) — 에 대한 조치가 각각 하나 이상 있어야 합니다.

담당이 없는 조치는 아무도 하지 않습니다. '백업 실패 시 알림' 보다 '마지막 성공 백업이 N분보다 오래되면 알림' 이 작업이 아예 돌지 않는 경우까지 잡습니다.