반드시 보존하라던 12기가의 실체

정리 대상 디렉터리에 DB 백업이라는 이름이 붙은 폴더가 있었다. 12기가였고 반드시 보존이라는 메모가 붙어 있어서 그냥 두면 되는 상황이었는데 안을 열어 봤다.

Open Table of contents

12기가의 구성

DB 덤프가 아니라 DB 서버 네 대의 로그 디렉터리였고 데이터가 한 행도 없었다.

리두 로그가 8기가를 차지하고 있었는데 리두 로그는 고정 크기 순환 버퍼라 테이블스페이스 파일 없이는 복구에 쓸 수 없다. 데이터 파일이 하나도 없는 이 아카이브에서 그 8기가는 아무것도 복구하지 못한다.

리두 로그와 중복을 걷어내니 12기가가 20메가가 됐다. 0으로 만들 수도 있었는데 느린 쿼리 로그 안에 그 시절 스키마에 대한 실제 쿼리 텍스트가 들어 있었다. 지금은 그 스키마 정의가 어디에도 없어서 쿼리 패턴을 역으로 볼 수 있는 유일한 자료였다.

그래서 남기되 남긴 이유를 함께 적었다.

ib_logfile0/1 제외 — 리두 로그는 순환 버퍼라 ibdata1·*.ibd 없이 복구 불가
db4/slow.log 보존 — 2020년 스키마에 대한 실제 쿼리 텍스트, 패턴 분석용

이걸 안 적으면 다음 사람이 또 12기가짜리 판단을 처음부터 하거나 남은 20메가를 찌꺼기로 보고 지운다.

네 서버의 압축 파일을 한 디렉터리에 풀려다 문제를 발견했다. 넷 다 최상위 디렉터리 이름이 같았다.

db3.tar.gz   → log/...
db3r.tar.gz  → log/...
db4.tar.gz   → log/...
db4r.tar.gz  → log/...

같은 곳에 풀면 서로 덮어써서 마지막에 푼 것만 남는다. 최상위를 서버명으로 치환해 다시 묶어 넷을 나란히 풀 수 있게 했다.

재압축한 뒤 제외 대상을 뺀 모든 파일의 해시를 원본과 하나씩 맞췄고 전부 일치했다. 새 아카이브에 리두 로그가 있는지도 셌더니 0건이었다.

여기서 멈추지 않았다. 0건은 없다는 뜻일 수도 있고 검사가 아무것도 안 셌다는 뜻일 수도 있다. 그래서 원본 아카이브에 똑같은 검사를 걸었더니 2건이 나왔다. 검사식이 실제로 잡는다는 것이 확인됐으므로 새 아카이브의 0건은 진짜 0건이다.

이 한 번의 대조군 실행이 검증을 검증으로 만든다. 없으면 그저 0이 나왔다는 사실만 남는다.

12기가를 삭제하지 않고 삭제 예정 디렉터리로 옮겼다. 20메가짜리를 한동안 써 보고 아쉬운 것이 없으면 그때 지운다. 지우는 것은 언제든 할 수 있고 되살리는 것은 못 한다.

남은 로그를 열어 보니 43분치였고 마지막 줄이 종료 완료였다. 운영 트래픽이 아니라 누가 가상 머신을 마지막으로 한 번 켜서 43분 돌리고 끈 기록이었다.

그리고 진짜 운영 덤프는 다른 데 있었다. 서버의 다른 디렉터리에 덤프 파일 11개가 48기가로 있었고 그것을 복원한 라이브 DB도 있었다. 반드시 보존이 붙은 12기가는 진짜 백업이 아니었고 진짜 백업은 라벨 없이 다른 데 있었다.

이 라벨은 붙일 당시에는 맞았을 것이다. 급하게 서버를 정리하면서 일단 로그 디렉터리를 통째로 떠 두자는 판단이었을 것이고 그때는 안에 무엇이 있는지 확인할 시간이 없었을 것이다.

문제는 라벨이 그 상태로 굳는다는 점이다. 판단의 근거는 사라지고 결론만 남으므로 다음 사람은 검증할 방법이 없어 그대로 둔다. 몇 년이고 그렇게 남는다.

그래서 크기를 가치로 읽지 않고 보존 라벨을 만나면 안을 확인하며, 줄이고 남긴 것에는 남긴 이유를 적고, 0건 검사는 대조군을 만든 뒤에 믿고, 원본은 격리하되 지우지 않는다.