Backup Restore Migration 운영

백업은 파일을 보관했다는 뜻이 아니라 정해진 RPO/RTO 안에서 실제로 복구할 수 있다는 약속이다.
복구 리허설은 백업 정책을 검증하고, 스키마 마이그레이션은 애플리케이션 버전과 데이터 구조의 호환성을 검증한다.
DB 백업, 파일 Object Storage 백업, 데이터 손실 사고 대응은 서로 다른 복구 경로를 가지므로 한 문서에 섞어 판단하면 안 된다.

Backup 종류와 복구 목표는 full backup, incremental backup, WAL/PITR, snapshot, logical dump를 RPO/RTO 기준으로 구분한다.
Restore Drill과 검증은 별도 환경에 복원한 뒤 데이터 건수, 핵심 API, 배치, 권한, 마이그레이션 상태를 확인한다.
Schema Migration 운영은 expand, deploy, backfill, contract처럼 애플리케이션 호환성을 유지하는 순서로 나눠야 한다.
파일 Object Storage 백업은 DB row와 object key, versioning, lifecycle, 삭제 정책을 함께 확인해야 한다.
데이터 손실 사고 대응은 먼저 추가 손상을 멈추고, 손실 범위와 기준 시각을 확정한 뒤 복구 또는 보정 방식을 선택한다.
Spring 백엔드 개발자는 테이블 의미, 트랜잭션 경계, 업로드/삭제 흐름, 배치 재실행 가능성을 설명할 수 있어야 한다.

백업이 있다는 말과 복구가 가능하다는 말은 다르다.
- 복구 권한, 복원 시간, 암호화 키, 애플리케이션 검증까지 통과해야 운영 가능한 백업이다.
마이그레이션 실패는 항상 rollback으로 해결되지 않는다.
- 이미 실행된 데이터 변경은 forward fix, 보정 배치, 읽기 전용 전환이 더 안전한 경우가 있다.
DB 백업만 있으면 사용자 파일도 복구된다고 착각하기 쉽다.
- DB에는 object key만 있고 실제 파일은 Object Storage에 있으므로 별도 versioning과 보관 정책이 필요하다.

RPO와 RTO는 각각 무엇을 결정하는가?
- RPO는 잃어도 되는 데이터 시간 범위, RTO는 복구 완료까지 허용되는 시간을 결정한다.
Restore Drill에서 백업 파일 복원 이후 무엇을 더 검증해야 하는가?
- 핵심 테이블, 주요 API, 배치, 마이그레이션 상태, 애플리케이션 권한과 설정을 확인해야 한다.
데이터 손실 사고에서 가장 먼저 해야 할 일은 무엇인가?
- 추가 쓰기와 자동 배치를 멈추고 손실 범위와 기준 시각을 보존 가능한 증거로 확정하는 것이다.

동블