2017 깃랩닷컴 운영 DB 오삭제 장애, 백업 5중 장치가 모두 실패하며 6시간 치 데이터 유실

사건 당일 17시 20분(UTC) 깃랩 엔지니어가 스테이징 환경 테스트를 위해 운영 데이터베이스의 LVM 스냅숏을 수동으로 만들었다. 깃랩닷컴의 정기 LVM 스냅숏은 24시간에 한 번만 찍히고 있었기 때문에 이 수동 스냅숏이 결과적으로 가장 최근의 복구 지점이 되었다. 이후 데이터 유실 범위가 이 시각부터 이어진 6시간 남짓으로 확정된 것도 같은 이유에서다. 당시에는 단순한 테스트 준비 작업이었으나 몇 시간 뒤 벌어질 대형 장애에서 사실상 유일한 생존 데이터가 된 셈이다.

19시경 깃랩닷컴 데이터베이스에 스팸 유입이 늘고, 어뷰징 신고로 플래그가 붙은 한 직원 계정을 삭제하려는 백그라운드 작업이 겹치며 부하가 크게 올랐다. 이 작업은 사실상 해당 계정과 연관된 대량의 데이터를 지우려 했고 DB에 지속적인 부담을 줬다. 부하 때문에 운영 DB에서 보조 DB로 가는 복제가 뒤처지기 시작했다. 팀은 스팸을 원인으로 의심하며 대응에 나섰고, 이 과정이 새벽 작업으로 이어지는 단초가 되었다.

23시경 복제 지연이 한계를 넘으면서 WAL(쓰기 선행 로그) 세그먼트가 보조 DB가 처리하기 전에 정리되었고 WAL 아카이빙도 켜져 있지 않아 복제가 끊겼다. 엔지니어는 보조 DB의 데이터 디렉터리를 비우고 pg_basebackup으로 다시 복제를 구축하려 했으나 여러 번 실패했다. 심야에 네덜란드에서 홀로 작업하던 엔지니어는 피로가 누적된 상태였고, pg_basebackup 동작에 관한 내부 문서도 충분하지 않았다. 이 지점에서 작업 대상 서버를 혼동할 위험이 커졌다.

23시 30분경 엔지니어가 보조 DB 대신 운영 DB(주 서버)에서 데이터 디렉터리 삭제 명령을 실행했다. 명령을 중단했을 때는 이미 약 300GB의 운영 데이터 가운데 4.5GB 정도만 남은 상태였다. 깃랩은 즉시 사이트를 내리고 복구 가능한 자료를 찾기 시작했다. 영향은 이슈와 머지 리퀘스트 등 DB에 저장된 정보에 한정되었고 Git 저장소와 위키는 별도 저장소에 있어 무사했다. 자체 설치형(셀프 매니지드) 고객도 영향을 받지 않았다.

복구 담당자들이 백업을 확인하자 pg_dump는 버전이 맞지 않아 빈 파일만 남겼고, 실패 알림 메일은 반송됐으며, S3 버킷은 비어 있는 등 5가지 백업·복제 수단이 하나도 제대로 작동하지 않았음이 드러났다. pg_dump는 응용 서버의 PostgreSQL 9.2 바이너리와 DB의 9.6 버전이 맞지 않아 아무 파일도 만들지 못했고, 실패 알림 메일은 DMARC 서명이 없어 반송되어 아무도 몰랐다. 애저 디스크 스냅숏은 NFS 서버에만 켜져 있었고 DB 서버에는 없었으며, S3 백업 버킷은 비어 있었다. 남은 것은 6시간 전에 수동으로 찍은 LVM 스냅숏 하나뿐이어서 일정 수준의 데이터 유실이 불가피해졌다.

스테이징 서버의 스냅숏을 운영 환경으로 복사하는 데 약 18시간이 걸렸는데, 병목은 네트워크나 CPU가 아니라 느린 애저 클래식 스토리지 디스크(약 60Mbps 수준)였다. 2월 1일 17시경 DB 복원이 끝났고 웹훅 복구 등 마무리 작업이 18시경 끝나 서비스가 정상화되었다. 17시 20분부터 23시 30분 사이의 DB 변경분이 사라져 프로젝트 약 5,000개, 댓글 약 5,000개, 신규 사용자 계정 약 700개가 영향을 받았다. 깃랩은 이 과정에서 상황을 공개적으로 알려 외부 개발자 커뮤니티의 주목을 받았고, 복구 지연 자체가 업계에서 백업 복원 테스트의 중요성을 보여주는 사례로 회자되었다.

깃랩은 2월 10일 장애 사후 분석 보고서를 공개하며 근본 원인을 수동 작업 실수와 취약한 백업 체계로 정리했다. 개선책으로 LVM 스냅숏을 시간 단위로 늘리고, 운영 DB에도 애저 디스크 스냅숏을 적용하며, 백업 복원 검증을 자동화하는 등 15건의 후속 과제를 제시했다. PostgreSQL 시점 복구(PITR) 도입 검토와 복제 절차 문서화, 데이터 내구성 책임자 지정도 포함되었다. 이 사건은 백업은 복원해 보기 전까지 백업이 아니라는 교훈으로 업계 교육 자료에 자주 인용된다.