Incident Library

IL-0538 Sakura Internet · 2012-01-05database

사쿠라 클라우드 스토리지의 일괄 삭제 작업이 고객이 쓰던 디스크 53개를 지웠고 되살리지 못했다

Sakura Internet 은 2011년 11월 15일 사쿠라 클라우드를 정식 출시했고, 2011년 12월 9일의 첫 장애부터 2012년 3월 말까지 스토리지 장애가 여러 번 이어졌다. 1월 초부터 사용자가 늘면서 사용자가 쓰는 디스크인 공유 파일 시스템의 수가 늘었고, 그 수가 늘수록 스토리지 장비를 조작하는 CLI 의 응답과 명령 처리가 느려졌다. 파일 시스템 수가 성능 저하의 원인 가운데 하나였으므로, 회사는 1월 5일 긴급 점검에서 부하 때문에 생성이 끝나지 않은 디스크와 해지된 디스크를 지우기 시작했다.

스토리지 부하가 매우 높아 통상 절차로는 삭제가 실행되지 않았다. 그래서 이 점검 전용 배치 명령을 만들어 불필요한 파일 시스템을 한꺼번에 지웠다. 이 명령은 리뷰와 테스트가 부족해서, 지울 파일 시스템의 종류를 잘못 정한 것을 아무도 찾아내지 못했다. 성능 저하를 막으려고 예비로 미리 만들어 둔 파일 시스템이 정상적으로 생성되지 않은 디스크로 잘못 인식됐고, 그 결과 가동 중인 디스크 53개가 지워졌다.

백업을 받는 구조는 있었지만 스토리지 부하로 백업 빈도가 떨어져 있었고, 지워진 디스크는 만든 지 얼마 되지 않아 백업이 시작되기 전이었다. 그래서 백업에서도 복원하지 못했다. 회사는 이 사고 뒤 삭제 절차를 단순하게 바꾸고 검증되지 않은 스크립트를 실행하지 않게 하는 재발 방지책을 정했다. 2012년 6월 25일의 보고서에서는 이 스토리지 장비를 자체 개발한 새 스토리지 장비로 바꾸기로 했다고 밝혔다.

심각도
–
영향 범위
53 Sakura Cloud disks that customers were using were deleted and could not be restored
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

2012년 1월 5일 긴급 점검에서 스토리지의 불필요한 파일 시스템을 한꺼번에 지운 뒤, 고객이 사용 중이던 사쿠라 클라우드 디스크 53개가 함께 지워졌다. 이 디스크들은 백업에서도 되살릴 수 없었다.

점검 전부터 스토리지는 부하에 시달리고 있었다. 1월 초부터 사용자가 늘면서 스토리지 위의 공유 파일 시스템 수가 늘었고, 스토리지 장비에 명령을 보내는 CLI 의 응답이 느려졌다. CLI 에 접속하는 데 걸리는 시간이 길어졌고, 디스크를 만들고 지우는 명령도 아주 오래 걸리거나, 타임아웃이 나서 끝까지 실행되지 않았다.

지워진 디스크는 백업에서 복원할 수 없었다. 백업 구조는 있었지만 스토리지 부하 때문에 백업 주기가 길어져 있었고, 지워진 디스크는 만든 지 얼마 되지 않아 아직 백업이 시작되기 전이었다.

증상 데이터 유실

원인

원인 운영 실수

구성 요소 클라우드 블록 스토리지데이터베이스 백업과 스냅숏
기여 요인 리뷰 누락미검증 백업
촉발
스토리지 부하가 너무 높아 통상 절차로는 삭제가 실행되지 않자, 이 점검만을 위해 배치 명령을 새로 만들어 불필요한 파일 시스템을 한꺼번에 지웠다. 리뷰와 테스트를 충분히 거치지 않은 이 명령이 예비로 미리 만들어 둔 파일 시스템을 생성에 실패한 디스크로 잘못 분류했다.

감지

–

조치

–

후속 조치

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 클라우드 블록 스토리지, 데이터베이스 백업과 스냅숏. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.