DB를 내보내는 서버와 백업을 받는 서버가 분리된 환경에서 백업 도구를 교체했습니다. 교체 직후 보내는 서버에서 새 버전의 status를 실행했더니 no completed backup: db가 나왔습니다. 설치 직후라 도구의 변경을 먼저 의심할 만했지만, 이 메시지가 어느 서버의 어떤 저장소를 조회한 결과인지 확인해야 했습니다.

같은 호스트에서 버전만 비교

교체 전에 보관한 이전 버전으로 같은 서버에서 같은 status 명령을 실행했습니다. 이전 버전도 동일하게 실패했습니다. 두 버전이 같은 위치에서 같은 결과를 냈으므로, 우선 두 버전이 공통으로 읽는 경로를 확인했습니다. 이 비교에서는 백업을 새로 보내거나 기존 데이터를 바꾸는 명령 대신, 현재 상태만 읽는 명령을 사용했습니다.

구현을 읽으니 status는 수신 저장소의 완료 기록을 찾아 해당 백업의 체크섬과 생성 시각을 확인했습니다. 백업을 만드는 서버가 전송을 준비할 때 쓰는 사본과는 위치가 달랐습니다. 받는 서버에서 같은 명령을 실행하자 오래됐다고 표시된 항목이 없었습니다. 11월 3일 운영 기록에서도 DB와 설정 백업이 받는 서버에 도착한 것을 확인했습니다.

백업을 실제로 복원한 별도 검사

10월 29일에는 최신 백업을 격리 환경에 실제로 복원했습니다. 기존 도구로 실행하자 19.98초 뒤 MySQL 오류 1146으로 멈췄습니다. 빈 DB에 테이블을 만들기 전에 테이블 단위 권한부터 적용한 것이 원인이었습니다. 계정을 먼저 만들고 스키마와 데이터를 가져온 다음 권한을 적용하도록 순서를 바꿨습니다. 같은 백업을 수정한 도구로 실행하자 80.41초에 복원이 끝났고, 기본 테이블 20개, 총 87행의 데이터 해시가 일치했습니다. 두 시간은 각각 오류가 나기까지와 복원이 끝나기까지 걸린 시간입니다. 이 복원은 준비된 격리 환경에서 실행했습니다.

새 배포 뒤 상태 명령이 실패하면, 이전 버전의 사본으로 읽기 전용 비교를 해 볼 수 있습니다. 버전만 바꿨는데 결과가 같다면, 그다음에는 명령을 실행한 위치와 도구가 실제로 읽는 저장소를 비교합니다. 이 사례에서는 서버 역할을 구분하자 같은 오류를 재현하면서도 올바른 위치에서 상태를 확인할 수 있었습니다.