매일 DB 백업은 성공하지만 실제 복원은 해 본 적이 없습니다. 장애 때 감당할 데이터 유실과 중단 시간을 기준으로 무엇을 검증해야 하나요?

백업 파일이 만들어졌다는 것과 실제 서비스를 복구할 수 있다는 것은 다릅니다. 복원이 가능한지, 필요한 암호화 키와 설정이 있는지, 정해진 시간 안에 다시 서비스할 수 있는지 확인해야 합니다. 허용할 데이터 유실인 RPO와 복구 시간인 RTO를 먼저 정하겠습니다.

매일 백업한다면 최근 변경을 얼마나 잃을 수 있는지와 로그를 이용한 시점 복구가 가능한지 봐야 합니다. 복제본은 빠른 전환에 도움이 되지만 잘못된 삭제도 복제될 수 있어 백업을 완전히 대체하지는 않습니다. 저는 별도 환경에서 실제 복원을 수행하고 주문·결제 관계처럼 반드시 유지돼야 하는 데이터 규칙과 데이터 건수, 계정 접근이 정상인지 검증하겠습니다.

복구 시간에는 데이터 복사만이 아니라 새 인프라 준비, 키 접근, DNS·트래픽 전환, 캐시 예열도 포함됩니다. 절차가 특정 사람의 기억에만 있으면 장애 중 오래 걸릴 수 있어 실행 가능한 복구 지침과 권한을 준비하겠습니다. 백업 접근은 제한하되 원본 계정이나 지역이 불능이어도 복구할 수 있는지 확인해야 합니다. 성공 기준은 백업 작업의 녹색 표시보다 실제 복구 훈련에서 약속한 유실과 시간 범위 안에 들어오는지입니다.

RPO와 RTO를 시계로 측정합니다

RPO가 1시간이면 마지막 복구 지점과 장애 시각의 차이가 1시간을 넘지 않는지 확인해야 합니다. 매일 전체 백업만 있다면 이 목표를 만족할 수 없으므로 WAL·증분 로그의 보관 간격, 마지막 로그 손상 때 사용할 지점을 확인합니다. RTO가 30분이면 복사 완료가 아니라 정의된 서비스 중단 시점부터 핵심 트래픽을 받을 때까지를 재며, 인프라 생성·키 승인·마이그레이션·인덱스 생성·DNS 전환·캐시 예열을 모두 포함합니다.

장애 종류와 일관성 기준을 분리합니다

운영자의 잘못된 삭제는 최신 복제본보다 삭제 직전 시점 복구가 필요하고, 지역 장애는 다른 지역의 백업과 암호화 키가 필요합니다. 복구한 환경에서 주문-결제 참조, 잔액 원장, 사용자 권한, 새 주문 쓰기와 이벤트 발행을 점검합니다. 여러 서비스의 백업 시점이 다르면 조정된 스냅샷이나 이벤트 로그의 처리 위치로 복구 기준점을 정하고 주문 ID별 상태를 대조하며, 맞지 않는 데이터는 임의로 삭제하지 않고 대사 상태로 표시합니다. 훈련은 개인정보 접근을 통제한 격리 환경에서 수행하며, 실패한 단계·키 승인 지연·복사 속도·트래픽 전환 시간을 기록해 RPO/RTO 숫자를 다음 훈련에서 다시 검증하겠습니다.

구체적인 경계 사례

RTO 측정의 시작점을 권한 승인 시점으로 늦추면 장애 탐지와 사람 호출에 걸린 시간을 숨깁니다. 서비스 중단 또는 조직이 정의한 복구 개시 기준부터 재개까지를 측정하고 탐지·의사결정·권한 확보 시간을 별도 구간으로 기록하겠습니다. RPO는 마지막 백업 파일 생성 시각이 아니라 실제 복원된 최신 유효 변경 시점과 장애 시각의 차이입니다.

복원 시험에서는 외부 결제·메일을 격리해 옛 outbox를 읽은 소비자가 실제 부수 효과를 다시 만들지 않게 합니다. 합성 데이터 시험 외에도 실제 백업의 읽기 가능성·키 접근·무결성을 통제된 환경에서 검증해야 합니다. 원본 계정 손실이나 삭제 권한 오남용에 대비해 백업과 복구 키의 장애·권한 경계를 분리하고, 한 경계의 손실이 전부를 지우지 못하게 하겠습니다.