# GitLabのプロダクションデータベースがエンジニアによって削除されました。300ギガバイト。

Published: 2026-09-10

2017年1月31日23:27 UTC: GitLabのエンジニアは、長い夜の終わりに壊れたレプリカと格闘し、db2の代わりにdb1のPostgreSQLデータディレクトリを削除しました。db1はプライマリでした。GitLab.comのデータベース約300GBが1〜2秒で消滅し、5つのバックアップおよびレプリケーションメカニズムのいずれも機能していませんでした。事後分析: スパイクから間違ったホスト名までのタイムライン、pg\_basebackupが停止しているように見えた理由、pg\_dumpが静かに失敗していた理由（9.6データベース上の9.2バイナリ、DMARCによってバウンスされた失敗メール）、YouTubeでライブストリーミングされた6時間前のステージングスナップショットからの18時間にわたる復元、そして誰が本当に責任を負うべきか。対応に関する評決: SHIP IT。

Canonical: https://thedailydiff.dev/ja/video/2026-09-10-gitlab-rm-rf/

## この動画の要点

- 2017年1月31日: プライマリのデータディレクトリでrm -Rvfを実行。約300GBが削除され、4.5GBが残る。
- 5つのバックアップすべてが失敗: 空のS3バケット (pg\_dumpバージョン不一致)、DBにAzureスナップショットなし、レプリカがワイプ、Webフックなしの日次LVMコピー
- 2月1日18:00 UTC: GitLab.comが6時間前の手動スナップショットから復旧。ライブドキュメント、ライブストリーム、修正リスト付きの非難なしの事後分析

## 翻訳されたトランスクリプト

オリジナルの英語ナレーションから翻訳されています。利用可能なオーディオとキャプションはYouTubeによって管理されています。

0:00 GitLabのエンジニアが間違ったデータベースサーバーでrm -rfを実行し、 GitLab.comの300ギガバイトが1〜2秒で消滅。 ホスト名を読み取るのにかかる時間とほぼ同じ。 2017年1月31日午後11時27分、 UTC。GitLabは誤って本番データを削除したとツイートし、 インシデントメモをインターネットに公開し、復旧をYouTubeでストリーミング。 プラットフォームで2番目に人気のあるライブストリームとなる。 翌日、文書化された情報: 5つのバックアップ手法のうち、

0:25 信頼できるものは一つも機能していなかった。 なぜそれが起こったのか、なぜそれが可能なのか、そして誰が実際に責任を負うのか。 これはThe Daily Diff、事後分析です。 午後5時20分: エンジニアが本番環境のスナップショットを作成し、 ステージング環境のロードバランサーをテストします。 午後7時: スパムがデータベースを攻撃し、さらにGitLabの従業員をハード削除するジョブが、 荒らしの報告により実行されます。 午後11時: レプリカが大幅に遅延し、プライマリが必要なログをすでに破棄していたため、

0:48 唯一の修正方法はレプリカをワイプしてプライマリを再度コピーすることでした。 pg\_basebackupは出力なしでハングアップします。 実際には、プライマリを静かに待っていたのですが、誰もそのことを知らず、 ランブックにも記載がありませんでした。 午後11時には退勤するつもりだったエンジニアは、空のデータディレクトリが 問題だと判断し、削除します。 db1上で。プライマリです。 彼は1〜2秒後に気づきます。およそ300ギガバイトのうち、

1:11 4.5ギガバイトが残っていました。バックアップは。 1つ目: pg\_dumpをS3に日次で。 バケットは空でした。 cronジョブはデータベースのないアプリサーバーで実行されるため、パッケージは 9.6データベース用のPostgreSQL 9.2バイナリを選択し、失敗し、 DMARC不足のためにバウンスされた失敗メールを送信します。 2つ目: Azureディスクスナップショット、ファイルサーバー向けには有効でしたが、 データベース向けには無効でした。

1:32 3つ目: レプリカ、1時間前に意図的にワイプされていました。 4つ目: 24時間前の日次スナップショット、ステージング同期によってすべてのWebhookが 削除されていました。5つ目: 無関係なテスト用の午後5時20分の手動スナップショット。 これが採用されます。 復元とは、ステージングディスクをAzureの安価なストレージ経由で 毎秒60メガビットで本番環境にコピーし直すことで、18時間かかります。 GitLab.comは2月1日午後6時に UTCで復旧しますが、6時間分のデータは古くなります。

1:58 git blame: 1文字違いの2つのホスト名と、誰も 復元したことのない5つのバックアップシステム。 エンジニアではありません。 CEOが署名した事後分析では、彼の匿名性を保ち、 本番プロンプトを赤くし、データ耐久性に責任者を割り当てます。 なぜなら、それまで責任者はいなかったからです。 被害範囲: 18時間の停止、6時間分のデータ損失、 約5000のプロジェクト、5000のコメント、

2:18 700人の新規ユーザー、そしてプログレスバーを見守る5000人。 Hacker Newsはライブドキュメントに1,162ポイントを与え、彼らに 「5つのバックアップのうち、なし」という一文を引用します。 評決、事後分析: 対応についてはSHIP IT。 彼らはインシデントを公開し、プロセスを非難し、修正リストを 課題番号とともに公開します。 月曜日の行動: バックアップを復元する。 一度も復元したことがなければ、それはバックアップではありません。

2:42 まだ話せないインシデントを コメントまたはdailydiff.devまでお寄せください。 以上が今日のdiffです。 AxrisiのNikoでした。 責任を持ってマージしましょう。

## 情報源

- [GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/) — about.gitlab.com
- [GitLab, "GitLab.com database incident" (Feb 1, 2017)](https://about.gitlab.com/blog/gitlab-dot-com-database-incident/) — about.gitlab.com
- [@gitlabstatus, "We accidentally deleted production data…"](https://twitter.com/gitlabstatus/status/826591961444384768) — twitter.com
- [@gitlabstatus, emergency maintenance notice](https://twitter.com/gitlabstatus/status/826572933304827904) — twitter.com
- [Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)](https://news.ycombinator.com/item?id=13537052) — news.ycombinator.com
- [Hacker News, the postmortem thread (377 points)](https://news.ycombinator.com/item?id=13619714) — news.ycombinator.com