backup 정책 — 우리는 매일 새벽 4시

백업은 필요하다는 걸 누구나 안다. 그런데 실제로 제대로 돌아가고 있는지 주기적으로 확인하는 팀은 많지 않다. 우리도 처음에는 “돌아가고 있겠지”라는 막연한 믿음으로 운영했다. 그 믿음이 흔들린 건 복원을 실제로 시도해봤을 때였다.

백업이 있어도 복원이 안 되는 경우

백업 스크립트는 cron에 등록되어 있었고, 파일도 쌓이고 있었다. 문제는 그 파일로 복원을 한 번도 해보지 않았다는 것이었다. 테스트 환경에서 복원을 시도했을 때, 파일은 있는데 권한 문제로 적재가 안 되는 상황이 생겼다. 백업이 있다는 것과 복원이 된다는 것은 다른 이야기다.

그 이후로 백업 정책을 다시 짰다.

우리 팀의 현재 정책

백업은 매일 새벽 4시에 돌린다. 이 시간을 선택한 이유는 간단하다. 서비스 트래픽이 가장 낮은 시간대이고, 새벽 4시 오류는 아침 출근 전에 알람이 오면 대응할 수 있는 시간이 있다.

백업 대상은 두 가지다. 데이터베이스 덤프와 업로드 파일 디렉터리다. 코드는 git이 있으니 별도 백업을 하지 않는다.

보존 정책은 7일 일간 + 4주 주간이다. 일간은 최근 7일치를 유지하고, 주간은 일요일 백업을 별도로 보관해서 4주치를 유지한다. 스토리지 비용과 복구 가능성의 균형점으로 이 정책이 현재 팀에 맞다고 판단했다.

백업 파일은 서버 로컬이 아닌 외부 스토리지에 저장한다. 서버가 날아가는 상황에서 같은 서버의 로컬 백업은 의미가 없다.

복원 테스트를 분기마다 한다

지금은 분기에 한 번, 실제 백업 파일로 스테이징 환경에서 복원을 시도한다. 복원이 성공하면 기록을 남기고, 실패하면 원인을 찾아서 스크립트를 수정한다.

이 작업이 번거롭게 느껴질 수 있지만, 실제 장애 상황에서 복원이 안 된다는 걸 처음 발견하는 것보다는 훨씬 낫다. 복원 테스트는 백업 정책의 일부다.

알림 설정

백업 성공/실패 여부는 슬랙 채널에 알림이 온다. 성공 알림도 보내는 이유는, 알림이 안 오면 스크립트 자체가 죽었다는 신호로 인식하기 위해서다. “조용한 성공”은 오류와 구분이 안 된다.

백업은 준비하는 것이 아니라 유지하는 것이다. 한 번 설정하고 잊어버리면 어느 순간 작동하지 않는 백업을 믿고 있는 상황이 된다.

— by slecs