テクノロジー
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット－ Publickey

気に入った記事をブックマーク

気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
記事を読んだ感想やメモを書き残せます
非公開でブックマークすることもできます

GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット－ Publickey

テクノロジーカテゴリーの変更を依頼記事元:

www.publickey1.jp

適切な情報に変更

エントリーの編集

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます

コメントを非表示にできますコメント表示の設定

ブックマークしました

ここにツイート内容が記載されますhttps://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

次回からTwitterへ自動リダイレクト

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

1573usersがブックマークコメント

344

コメントするにはログインが必要ですブックマークを追加

ブックマークを追加

よく使うタグ

GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット－ Publickey

1573 users

www.publickey1.jp

よく使うタグ

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページへ

記事へのコメント344件

注目コメント
新着コメント

odakaho「もう今日は自分がこれ以上sudoコマンドを実行しないほうがいいだろう」冷静で優秀な人だと思う。挽回しようとして状況悪化させる人が多い。

あとで読む

2017/02/02リンク

その他

verda本当に必要なときにないのがバックアップ

2017/02/02リンク

その他

hokkey避難訓練みたいに、数ヶ月に一度練習するべきなんだろうな…。

2017/02/02リンク

その他

htnmikiこんなときでもちゃんと寝るのホワイトだ

2017/02/02リンク

その他

localnaviYP氏が盛大にやらかしたのは間違いないが、それ以前にバックアップがまったく機能してなかったのはヒドすぎる。たまたま6時間前にバックアップを取ってたのは不幸中の幸いだが、頭と胃が痛みで爆発しそう。

2017/02/02リンク

その他

kabukawa対応中、とメッセージ表示されるより、何をしているのか見せる方が安心できる、と思うのは自分がエンジニアだからだろうか。なんか大変な「場」を「共有」するのって難しいけど良いなって思った。

2017/02/02リンク

その他

auient障害の回復試験は重要だと教えてくれる。/ サービスに限らず家庭でのバックアップでも。

2017/02/02リンク

その他

karia復旧の様子ストリーミング配信すげえ

2017/02/02リンク

その他

tetsuzinプライマリ「もしかして」セカンダリ「わたしたち」

2017/02/02リンク

その他

luccafortこのリカバリをYouTubeで残したというのは大いなる財産だな。この件から学ぶべきは緊急時こそ適切に休め、バックアップは定期的にチェックしろ、悲観的になるなという3点に尽きる気がする。

2017/02/02リンク

その他

mizdra伝説の回。もう5年経ったのか…

2022/04/13リンク

その他

poad1010またやらかしたのかと思ったら、2017年の記事だった。

2020/02/28リンク

その他

sasasin_netいやーこれ。久々に読んだ。ここから生還する自信は今でも無い

2020/01/29リンク

その他

NyohoGitLab、これは素晴らしいな。「リカバリのためのデータリストアの状況をYouTubeで生放送。待ち時間にエンジニアがユーザーの自由な質問に答えるゆるさも」

2018/08/18リンク

その他

nihonbuson"YP氏は、もう今日は自分がこれ以上sudoコマンドを実行しないほうがいいだろうと言って、リストア作業をJNに依頼。" / この判断ってすごく大事。自分で何とかすると悪化したりするので、しないという判断は良いこと。

2017/08/19リンク

その他

foobarchocoboバックアップデータそれぞれが、全く整合性チェックどころか実体さえ、確認してなかったということだよね？どう褒めていいのか分からないや。

2017/03/19リンク

その他

kita-tuba GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット

unclassified

2017/02/21リンク

その他

t_osawa“YP氏は、もう今日は自分がこれ以上sudoコマンドを実行しないほうがいいだろうと言って、リストア作業をJNに依頼。”

2017/02/09リンク

その他

satzz“リカバリ作業を見守る3人のGitLab.comエンジニアはいずれも自宅からリモートで操作。ストリーミングを見ていると、ときおり子供の声らしきものが聞こえます”

2017/02/08リンク

その他

homararaギガバイトのデータベースだと、バックアップ取る時間と退避スペースを確保するのも大変だから、「作業前にフルバックアップ取っておこう」というのができない環境もままあるんだよね。当然、しくじったら即死。

2017/02/08リンク

その他

wdr_s考えただけで胃が傷むけど、かなり冷静な対応だったんだなぁ。

2017/02/08リンク

その他

kei_0000失敗は隠さない / 無理に一人で挽回しようとしない / 復旧作業を公開 / 日頃からバックアップを確認 / 明日は我が身

2017/02/06リンク

その他

jitsu102こちらも参照https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/https://goo.gl/3g4384 https://togetter.com/li/1076845

2017/02/06リンク

その他

hbkmrm -rしちゃったんですか

2017/02/06リンク

その他

tamaxyoダメだと思ったタイミングで手を離した決断はすごいな、多分正解だ。あと、復旧をストリーミング配信するとか、すごい時代だなぁ。自分だったら確実に手が震える

2017/02/06リンク

その他

fake-jizoソースコード管理サービスを提供するGitLab.comは、1月31日23時頃（世界協定時。日本時間2月1日15時頃）、操作ミスから本番データベースのデータの大半を失い、サービスが停止するという事故を起こしました。 Tags: via Pocket

2017/02/05リンク

その他

masadreamうわわ…

2017/02/04リンク

その他

santo「mistake will happen, sir」という、昔見たコントドラマのセリフを思い出した。

2017/02/04リンク

その他

ebo-cユーチューバー「リカバリしてみた。」

2017/02/04リンク

その他

t-sat「正・副・予備・まさかの時の・こんな事も有ろうかと、全て駄目です」

webservice

2017/02/04リンク

その他

majidaruとてもクールだと思う

2017/02/04リンク

その他

airj12起きた事は起きた事として置いといて真剣にオープンにでもマイペースに対応するの素敵

2017/02/04リンク

その他

kazuya53自分がこれ以上触らない方が良いと判断して後を委ねたのは正しい。こういう異常事態を引き起こした中でリカバリーしようとした判断はだいたい何やっても失敗するから。

2017/02/03リンク

その他

bata64手に汗握る展開。sudo操作を他人に委ねたくなるYP氏の気持ちは良く分かるが、何故分かるのか思い出を辿るとうっ、頭痛が・・・。

2017/02/03リンク

その他

barlog落着してから見た身だけど、一連の経緯は感謝すべき事象だと思います。

2017/02/03リンク

その他

Domino-Rこれ全然アクシデントじゃないよね？　必然的に起こってる。運用管理能力が甚だ疑問。バックアップが全部ダメだったなんて「アクシデント」か？　恥ずべき事例。

2017/02/03リンク

その他

animist怖い

2017/02/03リンク

その他

cybergeneオペレーターが致命的なミスを犯すのは誰もが通る道。バックアップが機能してなかったのはご愁傷様としか。

2017/02/03リンク

その他

reachoutバックアップが全部動いてなかったというの悲惨すぎる。復旧もエンジニア向けサービスだから公開しても理解されるが、これが一般向けシステムだったらとんでもない大炎上祭り。

2017/02/03リンク

その他

rochefort年に一度は避難訓練みたいにリストア訓練すべきやな // 引き継ぎなしで任された会社のリポジトリバックアップ未稼働問題（sync未稼働、s3backup失敗）とダブって他人事じゃない

GitLab

2017/02/03リンク

その他

コメントするにはログインが必要ですログインしてコメント

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー

はてなブックマークボタンを作成して埋め込むこともできます

規約違反を報告

いまの話題をアプリでチェック！

バナー広告なし
ミュート機能あり
ダークモード搭載

アプリをダウンロード

usersに達しました！

さんが1番目にブックマークした記事「GitLab.comが操作...」が注目されています。

気持ちをシェアしよう

ツイートする

GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット－ Publickey

果たしてGitLab.comで何が起きたのでしょうか？これまでの経緯をまとめました。スパムによるトラフィ...果たしてGitLab.comで何が起きたのでしょうか？これまでの経緯をまとめました。スパムによるトラフィックのスパイクからレプリケーションの不調へGitLab.comは今回のインシデントについての詳細な経過を「GitLab.comDatabase Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.comDatabase Incident |GitLab」にも掲載されています。これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時