만들어뒀다는 것과 되살아난다는 것
백업을 여러 층으로 깔았다. 야간에 도는 자동 백업, 그걸 서버 바깥으로 한 벌 더 보내는 보관, 서버 통째 스냅샷, 배포 직전에 한 번 더 뜨는 덤프.
층을 나눈 이유는 단순하다. 하나만 있으면 그 하나가 실패했을 때 아무것도 안 남는다.
그런데 층을 아무리 쌓아도 확인이 안 된 게 하나 있었다. 이게 실제로 되살아나느냐다. 백업 파일이 매일 생기는 것과, 그 파일로 서비스를 되돌릴 수 있는 것은 다른 얘기다. 앞은 매일 확인되지만 뒤는 사고가 나기 전까지 한 번도 확인되지 않는다.
그래서 마지막 단계로 복구 리허설을 했다. 이걸 건너뛰면 앞의 층들이 전부 종잇조각이 된다.
1.6초, 그리고 깨진 글자
보관해둔 덤프를 하나 골라 받았다. 로컬에 일회용 DB를 하나 띄우고, 그 덤프를 복원했다.
1.6초 걸렸다.
그리고 열어봤다. 한글이 깨져 있었다.
하루를 들여 깔아놓은 백업이, 되살리면 글자가 망가진다는 뜻이었다.
깨진 건 백업이 아니었다
확인해보니 파일은 멀쩡했다.
문제는 그 파일을 열어보는 쪽의 문자셋 설정이었다. 접속하는 클라이언트가 다른 문자 규격을 가정하고 있어서, 멀쩡한 데이터를 잘못 해석해 보여준 것이다. 접속 설정을 맞추니 그대로 나왔다.
만약 여기서 "복원하면 한글이 깨진다"고 결론냈으면 어떻게 됐을까. 그 문장을 절차서에 적어두고, 멀쩡한 백업을 못 믿게 됐을 거다. 진짜 사고가 났을 때 쓸 수 있는 걸 앞에 두고 다른 방법을 찾느라 시간을 썼을 거다. 백업이 고장 난 게 아니라 백업에 대한 내 판단이 고장 나는 쪽이 더 위험하다.
그래서 두 가지를 했다. 백업 스크립트가 파일을 만들 때 문자 규격을 명시하도록 박아뒀고, 리허설 절차서에 이 함정을 적어뒀다 — "글자가 깨져 보이면 파일부터 의심하지 말고 접속 설정을 먼저 볼 것".
눈으로 보는 걸론 부족하다
글자가 제대로 나온다고 복원이 성공한 건 아니다. 눈으로 보는 건 화면에 뜬 일부만 보는 거니까.
그래서 백업을 뜰 때 항목별 건수를 같이 기록해둔다. 복원한 쪽에서 같은 걸 세서 그 기록과 맞춰봤다. 7개 항목 전부 일치. 구조 변경 이력도 깨끗하게 따라와 있었다.
이렇게까지 하는 이유는, 부분 손실이 제일 무섭기 때문이다. 아예 복원이 안 되면 바로 안다. 90%만 복원되면 한동안 모른다. 그리고 모르는 동안 그 위에 새 데이터가 쌓인다.
남길 것
절차서에는 실측 소요시간도 같이 적었다. 사고가 났을 때 필요한 건 "백업이 있다"가 아니라 "몇 분이면 돌아온다"니까. 이 숫자가 있으면 사고 상황에서 판단이 빨라진다. 되돌릴지 버티면서 고칠지를 정할 수 있다.
정리하면 이날 배운 건 두 겹이다.
만들어둔 걸 한 번은 되살려봐야 한다. 그리고 되살려본 결과를 잘못 읽을 수도 있다. 확인을 했다는 사실이 확인이 맞았다는 뜻은 아니다. 그래서 판단 기준을 머리에 두지 않고 절차서에 적어두는 편이 낫다. 다음에 같은 화면을 보는 사람은 그때의 나만큼 침착하지 않을 테니까 — 그게 몇 달 뒤의 나라도.
