website: backup-db.sh 실행권한 git에 커밋
DB 백업 스크립트의 실행권한이 git에 반영되지 않아 발생한 알람 사고를 수습하고, 같은 문제가 재발하지 않도록 파일 모드를 커밋한 PR입니다.
요약
infra/backup-db.sh의 실행권한(755)을 git 히스토리에 정식으로 커밋한 PR입니다. 기존에는 이 파일이 100644(실행 불가) 상태로 저장되어 있었고, 서버에서는 과거에 수동으로 걸어둔 chmod +x 덕분에 눈치채지 못한 채 잘 돌아가고 있었습니다. 그러다 다른 PR이 머지되며 서버가 파일을 재체크아웃했고, 그 순간 git이 기억하던 644 모드로 되돌아가면서 cron이 조용히 실패했습니다. 이 PR은 사고 원인이 된 파일 모드 자체를 고쳐서 커밋한 것으로, 생성 1분 만에 dev 브랜치에 머지됐습니다.
배경 및 목적
2026년 7월 13일 18시경, stage/prod DB 백업이 26시간 동안 실행되지 않았다는 CRITICAL 알람이 울렸습니다. 원인을 추적해보니 backup-db.sh가 git에 한 번도 755(실행 가능) 권한으로 커밋된 적이 없었습니다. 계속 100644 상태였던 겁니다.
그런데도 그동안 문제없이 돌아갔던 이유는 단순했습니다. 과거 어느 시점에 서버에서 수동으로 chmod +x를 걸어놨기 때문입니다. 파일 내용은 git이 관리하지만, 로컬에서 걸어둔 실행권한은 git이 추적하지 않는 한 pull/checkout 한 번에 사라질 수 있는 상태였던 거죠.
그러다 7월 13일 14:46 KST에 머지된 PR #110이 이 트리거가 됐습니다. 서버가 배포 과정에서 해당 파일을 재체크아웃하면서, git에 기록된 644 모드로 조용히 되돌아간 겁니다. 이후 18:00 UTC cron이 스크립트를 실행하려다 Permission denied로 실패했지만 에러가 눈에 띄게 드러나지 않았고, 결국 18:04 KST 알람 메일로 뒤늦게 발견됐습니다.
구현 내용
서버 쪽 응급 조치는 이 PR 이전에 이미 끝난 상태였습니다:
chmod +x로 실행권한 즉시 복구- 밀렸던 07-13 백업을 수동으로 1회 실행 (prod·stage 업로드 및 메트릭 전송까지 확인)
- 알람이 OK로 전환되는 것 확인
이 PR에서 한 일은 근본 원인 제거입니다. git update-index --chmod=+x 명령으로 infra/backup-db.sh의 파일 모드를 100644에서 100755로 바꿔 git 인덱스에 반영했습니다. 코드 내용 자체는 한 줄도 바뀌지 않았고(추가/삭제 라인 0), 오직 파일 메타데이터인 실행권한만 커밋에 포함됐습니다.
git update-index --chmod=+x infra/backup-db.sh
git commit -m "fix(infra): backup-db.sh 실행권한 git에 커밋"
이렇게 하면 이제 이 파일은 어떤 pull이나 checkout에서도 항상 755 상태로 유지되고, 서버가 코드를 재체크아웃해도 더 이상 실행권한이 벗겨지지 않습니다.
완료조건 체크리스트에서 서버 백업 정상화와 git 파일 모드 수정은 확인됐고, "머지 후 다음 pull에서도 실행권한이 유지되는지"는 다음 배포에서 자연스럽게 검증하는 것으로 남겨뒀습니다.
배운 점 및 개선점
이번 사고는 "로컬에서 잘 되던 게 서버에서도 잘 될 거라는 가정"이 얼마나 위험한지 보여주는 사례였습니다. 실행권한처럼 파일시스템 레벨의 설정은 git이 명시적으로 추적하지 않으면 재체크아웃 시점에 언제든 사라질 수 있는데, 그동안은 수동 chmod에 의존하고 있었기 때문에 문제가 잠복해 있었던 겁니다. 심지어 트리거가 된 PR #110은 이 스크립트와 직접 관련 없는 변경이었을 가능성이 높은데, 재체크아웃이라는 부수 효과로 인해 전혀 예상 못한 곳에서 장애가 터진 셈입니다.
앞으로는 cron으로 도는 스크립트나 배포 파이프라인에 걸리는 실행 파일들은 git 파일 모드가 올바르게 커밋돼 있는지 한 번씩 점검해볼 필요가 있어 보입니다. git ls-files -s로 각 파일의 모드를 확인하는 습관을 들이거나, CI에서 주요 스크립트들의 실행권한을 검증하는 단계를 추가하는 것도 재발 방지에 도움이 될 것 같습니다. 또한 백업 실패가 26시간 동안 감지되지 않았다는 점에서, 알람 임계값이나 감지 주기를 더 촘촘하게 가져가는 것도 고민해볼 만합니다.