← 블로그 목록
35 서비스 운영

백업을 복구 증거로 바꾸는 소규모 서비스 드릴 런북

백업 완료 로그만 믿지 않고 격리 환경에서 복구를 실행해 RPO·RTO, 데이터 대조, 권한과 승인 기록까지 증명하는 소규모 서비스용 드릴 런북입니다.

백업을 복구 증거로 바꾸는 소규모 서비스 드릴 런북 대표 이미지

백업이 성공했다는 로그는 복구가 가능하다는 증거가 아닙니다. 실제 백업을 승인된 격리 환경에 복원하고, 서비스가 읽는 핵심 데이터와 파일을 대조하고, 걸린 시간과 누락을 기록해야 비로소 복구 능력을 설명할 수 있습니다.

AWS의 백업 보안 지침도 복구 절차를 정기적으로 테스트하고 복구 목표를 검증하는 운영을 권장합니다.이 글은 그 원칙을 작은 팀이 실행할 수 있도록 범위 선정, 실행 순서, 증거 묶음, 실패 시 중단 규칙으로 바꿉니다.

백업 범위와 RPO를 정한 뒤 격리 복구와 데이터 대조로 증거를 만드는 드릴 흐름도

드릴 전에 복구 목표와 경계를 합의하기

RPO는 장애 시 잃어도 되는 데이터의 시간 범위이고 RTO는 서비스를 다시 사용할 수 있게 하는 데 허용되는 시간입니다. 숫자를 먼저 정하지 않으면 복구가 빨라도 충분한지, 최신 데이터가 빠져도 허용되는지 판단할 수 없습니다. 결제·회원·첨부 파일처럼 서로 다른 보존 요구를 한 목표로 뭉개지 말고 목록으로 나눕니다.

드릴 대상은 운영 데이터의 복사본과 테스트용 자격 증명으로 제한합니다. 운영 저장소에 쓰기 권한을 그대로 사용하지 않고, 네트워크를 격리하며, 원본을 덮어쓰지 않는 복원 지점을 지정합니다. 실행자·승인자·관찰자를 분리하면 성공을 스스로 판정하는 오류를 줄일 수 있습니다.

런북의 세 묶음: 준비, 복구, 대조

준비 단계의 산출물은 복구 요청서입니다. 대상 백업 ID, 생성 시각, 예상 RPO·RTO, 격리 환경, 승인자, 비상 중단 연락처를 한 장에 적습니다. 파일 백업과 데이터베이스 백업의 시점이 다르면 가장 오래된 시점을 기준으로 예상 손실을 계산합니다.

복구 단계에서는 타이머를 시작하고 원본과 다른 이름의 데이터베이스·버킷에 복원합니다. 스키마 마이그레이션이 필요한 경우 자동 실행하지 말고 복원본의 버전과 호환성을 확인합니다. 애플리케이션을 연결한 뒤 읽기 전용 대표 경로를 먼저 호출하고 쓰기 테스트는 별도 샘플 테넌트에서만 수행합니다.

복구 드릴에서 원본과 복구본의 건수, 상태, 스냅샷 시각을 대조하는 샘플 표

대조 단계는 ‘페이지가 열렸다’보다 업무 불변식을 확인합니다. 주문 건수와 합계, 결제 상태 분포, 최근 생성 시각, 첨부 파일 해시 또는 크기, 외부 연동 큐의 미처리 수를 원본 스냅샷 기록과 비교합니다. 차이가 있으면 성공으로 닫지 말고 차이의 원인과 허용 범위를 기록합니다.

  • 준비: 승인, 범위, 백업 ID, RPO·RTO, 격리 자원을 기록한다.

  • 복구: 원본과 분리된 저장소에 타이머와 명령 로그를 남긴다.

  • 대조: 건수·합계·상태·파일·큐를 독립된 체크리스트로 확인한다.

  • 종료: 증거 링크와 남은 결함, 후속 담당자·기한을 승인받는다.

예시: 새벽 스냅샷으로 주문 서비스를 복구하기

가상 사례의 입력은 10시 스냅샷, RPO 15분, RTO 60분, 주문 12,480건입니다. 결정은 운영 DB가 아닌 격리 DB에 스냅샷을 복원하고 앱을 읽기 전용으로 연결하는 것입니다. 중간 산출물은 복구 시작·완료 시각, 복구된 스냅샷 시각, 주문 건수·상태 대조표, 실행 명령 해시입니다.

예상 결과는 10시 07분 시점으로 복구되어 RPO 안에 있고 42분에 읽기 검증을 끝내는 것입니다. 주문 건수가 12,480건과 일치하고 paid·refunded 분포가 원본과 같으면 기능 검증을 통과시킵니다. 첨부 파일 해시가 다르면 서비스 복구 성공과 파일 복구 실패를 분리해 기록합니다.

실패·중단 규칙과 복구 경로

복구가 실패했을 때 같은 명령을 무한히 반복하지 않습니다. 백업 암호 해독 실패, 스키마 버전 불일치, 파일 누락, RTO 초과를 각각 중단 사유로 분류하고 원본 접근을 차단한 채 다음 후보 백업이나 별도 복구 도구로 전환합니다. 모든 시도는 시간과 오류를 남겨 다음 드릴의 입력으로 삼습니다.

복구본에서 애플리케이션이 쓰기를 수행해 데이터가 오염되었다면 즉시 격리하고 해당 환경을 폐기합니다. 운영으로 되돌리는 대신 새 복구 지점에서 재시작하며, 권한 토큰을 폐기하고 재발급합니다. 실제 재해가 아닌 훈련에서 운영 원본을 건드렸다면 훈련은 실패로 종료하고 접근 경계를 먼저 고칩니다.

증거 묶음과 다음 드릴의 입력

런북의 완료물은 체크 표시가 아니라 재현 가능한 증거 묶음입니다. 승인 요청, 백업 메타데이터, 명령·로그, 복구 시각, 대조 쿼리 결과, 스크린샷 또는 해시, 실패와 후속 티켓을 같은 드릴 ID로 묶습니다. 민감한 데이터는 샘플링·마스킹하고 접근 권한의 만료도 기록합니다.

드릴이 끝나면 RPO·RTO 달성 여부, 수동 단계 수, 가장 오래 걸린 단계, 누락된 알림을 회고합니다. 목표를 달성하지 못했다면 ‘백업 주기를 줄인다’처럼 원인과 연결된 조치, 담당자, 기한을 정하고 다음 드릴에서 다시 측정합니다. 숫자를 바꾸어 실패를 숨기는 것은 복구 능력을 개선하지 못합니다.

관찰 가능한 완료 조건

드릴은 복구본에서 대표 업무 조회가 성공하고, 원본과 대조한 핵심 불변식이 모두 판정되며, 복구 시간과 데이터 손실 시간이 목표 안에 있고, 운영 원본에 쓰기가 없었다는 로그가 남을 때만 완료로 닫습니다. 하나라도 빠지면 ‘부분 성공’으로 기록하고 결함 티켓을 발행합니다.

마지막으로 승인자가 증거 묶음의 링크를 열어 같은 결론을 재현할 수 있는지 확인하세요. 다음 예정일과 변경된 런북 버전을 기록하면 백업은 저장 작업이 아니라 실제로 시험된 복구 계약이 됩니다.