GitLab.comが誤って本番DBを削除、バックアップも取れていなくて大騒ぎに 57
ストーリー by hylom
なぜバックアップが取れていないのだ 部門より
なぜバックアップが取れていないのだ 部門より
あるAnonymous Coward曰く、
ソースコード管理サービスを提供するGitLab.comが1月31日、管理者の操作ミスにより本番DBのデータ300GBを誤ってディレクトリごと削除してしまい、サービス停止状態に陥ったことが明らかになった（公式報告のGoogle Doc、Publickey、The Register、Slashdot）。
GitLab.comはオープンソースのソースコード/プロジェクト管理ソフトウェアGitLabを使ったホスティングサービスを提供するクラウドサービスで、GitリポジトリやWiki、Issue管理といった機能を提供している。報告によると、同社では31日、スパムユーザーの負荷によりセカンダリDBに異常が発生したことから、セカンダリをクリーンしてからレプリケーションを復旧する作業を実施していたとのこと。しかし作業がうまくいかず、再度セカンダリをクリーンしようとして、誤って残るプライマリをクリーンしてしまったという。同社は直ちにバックアップからの復旧を試みるも、5系統あるはずのバックアップはいずれもエラーなどで実は機能していないという事が判明、一時騒然となった。なお失われたDBはIssueやMergeリクエストのもので、Gitリポジトリ本体とWikiは無傷だという。
その後、たまたま作業の6時間前に取られていたスナップショットが思いだされ、これを元に復旧作業が進められているのだが、タレコミ時点では何故かその様子がYouTubeでライブ配信されるという不思議なことになっている。なおミスを起こしたYP氏は「もう今日は自分がこれ以上sudoコマンドを実行しない方がいいだろう」と語っているという。
バックアップの正常動作のチェック (スコア:4, 参考になる)
かく言う私自身も、今のように複数系統のバックアップもストレージ多重化もハードウェアの制約と高価なために中小企業では導入が難しかった頃、小規模システムながら更新前バックアップ処理を失敗した状態で年次更新手順を失敗、取りあえず当年度データは無事で次年度データは作成した物の前年度の月次データを丸々紛失、担当者に帳票から再入力で再現してもらい約半年で復旧してもらったという最悪な状況をつくったことがあったから、複数系統のバックアップとその正常性にはいつも気を使うようになったのですが・・・。
Re:バックアップの正常動作のチェック (スコア:5, 興味深い)
実際ありがちなんだよな、restoreできないバックアップ処理系になってるパターン
長く運用されてデータ量増えたりスケールアウト|アップされたのにバックアップ側変更無しで実はトラブってて
JCLだの死活監視だのからはsuccessに見えてるけどいざそのとき使えないゴミデータがバックアップされてるやつ。
Re:バックアップの正常動作のチェック (スコア:5, 参考になる)
私も引継ぎマニュアルをみて、ミラーリングとバックアップサーバありね、ふんふん…と見ただけで流しちゃって
その翌月、年次点検で電源落とした時に見事にクラッシュ
ミラーリングのはずのHDDは１つしか刺さっておらず、バックアップは数年前
月額制のブラウザゲーなので壊れちゃいましたゴメンナサイは出来れば避けたいというかヤバイ
メンテの為停止しますとなってから復旧しないため、２chにデータとんだんじゃね？って書かれるしまつ！
結局復旧業者で何とか直ったけど一週間止まったよ
手順あっても実際に確認はほんと大事
バックアップ終了メールきててもメール文面をみないとか
Re:バックアップの正常動作のチェック (スコア:5, 興味深い)
> 年次点検で電源落とした時に
法定点検で電源落としたら再開時にネットに接続できなくなって、原因調べたらISPへの料金滞納が発覚したというひどい話もあったな。フレッツはISP側から回線切断することができないのでこっちから切るまで発覚しないらしい。
Re: (スコア:0)
ああやっぱり回線って強制切断は出来ないのか
学生時代にアレでアレな事をしている時にISPへの接続がbanされる時でも接続中なら大丈夫だった事がある と聞いた
Re: (スコア:0)
確認も大切だが復元テストも大事
Re:バックアップの正常動作のチェック (スコア:1)
実際に復元テストしようにも、テスト用の復元先環境なんか、オンプレミスだと用意して貰えないって事の方が多い気がする。
Re: (スコア:0)
あるある・・・
Re: (スコア:0)
SEしてた頃、しなかったな…復元テスト…。
もし失敗したら、また１から環境の作り直し。確実に納期に間に合わない！
先輩に「これほんとにリストアできるんですかね？」と聞いたら、
「さあ？」という答えだったのが今でも忘れられない。
Re: (スコア:0)
そんな時嘘でもたぶんといえるそんな優しい人に私はなりたい
Re: (スコア:0)
復元テストといえば
MySQLのバックアップが作られていた環境で
バックアップの手順として、OSコマンドでフォルダをコピーという形で取得されていたんだけど
止めずにコピーしていたので、復元できるかテストをしたらやっぱり壊れてた
壊れたデータを取ってる可能性があるので、見直しはほんとだいじ
Re:バックアップの正常動作のチェック (スコア:3, 参考になる)
保守費を貰って無い会社でバックアップの設定だけしてその後はノータッチの場合、トラブルが起きてバックアップから戻してくれと依頼されてバックアップを見たら、きちんと取れてない事がよくある。むしろ、きちんと取れてた事の方が珍しい。
自社運用でも、きちんと担当者を決めたり工数を確保したりしとかないと、今回のように設定したまま誰もチェックしない放置状態になるんじゃないかな。
Re:バックアップの正常動作のチェック (スコア:1)
待機系があるなら定期的に待機系に復元して運用系と切り替えしてみる(つまり平時から運用に組み込む)のが確実ですね。
Re:バックアップの正常動作のチェック (スコア:1)
こういうデッカイ系にはきつけど、サーバインスタンス起動する系とかだと、 Chaos Monkey でわざとエラーを適時おこすってのもあるしね...
# 参考URL:
# http://www.publickey1.jp/blog/12/chaos_monkeynetflix.html [publickey1.jp]
# http://www.publickey1.jp/blog/14/netflixchaos_monkeyamazon_ec2.html [publickey1.jp]
でも難しいよね
M-FalconSky (暑いか寒い)
Re: (スコア:0)
そういうのはお家のお宝画像のバックアップに失敗したときに覚えた。
確かDVDにバックアップしたのだがデータが化けていて…
別にピンク色なあれではなく映画の壁紙だとかそんなもの。
Re: (スコア:0)
重大なミスというのは重なるものです。ハインリッヒの法則ですね。
Re: (スコア:0)
これで担当者責められるとしたら、その組織管理者にダメ判定下しますね。
システム（バックアップ）ミスをカバーするために、想定外のことをやってる状態なので。
この場合「どうでも良いから何とかしろ」的に急かすのも同罪。
Re: (スコア:0)
とりあえずGitlabについて言えば、今回の件を理由に処分される従業員はいないと語っているようです。
遅刻 (スコア:1)
随時報告されるとあまり怒りを感じないのと同じでしょうか
# でも目を背けずにはいられなかった
バックアップもスナップショットもとっていただけ、 (スコア:1)
ファーストサーバよりましだわな。
機能してないにしても。
しかし、なぜ一連のファーストサーバのストーリーが関連リンクにないのだろう。
https://it.srad.jp/story/12/06/22/090229/ [it.srad.jp]
https://it.srad.jp/story/12/06/25/0723232/ [it.srad.jp]
https://security.srad.jp/story/12/08/01/0057216/ [security.srad.jp]
https://security.srad.jp/story/12/06/30/1941246/ [security.srad.jp]
https://it.srad.jp/story/12/08/13/0945241/ [it.srad.jp]
消滅したのがGitリポの方だったら (スコア:0)
各利用者のローカルにクローンが残ってるだろうからまだ良かったのにね。
# そういう話ではない
Re: (スコア:0)
実際Issueぶっとばされるのは結構キツいよね。
リポジトリのissueディレクトリに実体があるようなシステムだったら便利かなあ。検索とか。
これが文化の違いか (スコア:0)
> もう今日は自分がこれ以上sudoコマンドを実行しない方がいいだろう
担当者を晒したり、対外的に愚痴をこぼしたり、ちょっと理解不能な集団だな。
サイトTOPに社員らしき顔写真晒してる時点で十分イカレてるけど。
そもそも、DBのクリーニングとディレクトリ削除の因果関係が不明だし、レプリケーション状態のセカンダリだけを操作するって発想が理解できないんだけど。
DB管理上の問題があるんじゃねーのかな。
Re:これが文化の違いか (スコア:3, 興味深い)
それを「晒し」と感じた時点でもう負けじゃないですかね。
この人たちは最初から「この件で解雇される従業員は絶対にいません」と断言していましたし、
険悪なムードにももならずに淡々と顔出しで復旧作業を続け、その経緯をリアルタイムで公開していましたし、
逆に魅力的な会社だと思った人の方が多いんじゃないでしょうか。
バックアップが間違っていた件は擁護できませんが、その原因を誰に言われるでもなく全部公開しており、
透明性がありすぎてこちらが心配になるくらいでした。
こんなに内部事情を公開して大丈夫かという懸念に対しても「security by obscurityなんかに頼りません、
この作業ログを晒すことで脆弱になるとは思っていません」と力強く発言する感じとか、ちょっとカッコ良かったです。
（まあソフトウェア自体オープンソースですし）
Re:これが文化の違いか (スコア:2, 興味深い)
> もう今日は自分がこれ以上sudoコマンドを実行しない方がいいだろう
ここは笑ったけど、自分から言いだすのは確かに文化の違いかなぁ
他人に言ってあげたことはあるけど・・トラブって正常な判断が出来なくなってる人に対応させても良いことないからね。
でも日本の組織だと、凹んだやつを見つけるとここぞとばかりに叩く上司が多いんだよな
技術力がない人が上司になって、すべての責任を部下にって、よく見かけたなぁwww
Re:これが文化の違いか (スコア:3, 参考になる)
>> もう今日は自分がこれ以上sudoコマンドを実行しない方がいいだろう
>ここは笑ったけど、自分から言いだすのは確かに文化の違いかなぁ
笑うどころか、とても賢明な判断と思えました。
もし君がこれを言い出せない文化にいるなら脱出をお勧めする。いや実際、君のためになると思う。
Re: (スコア:0)
それなwww
突っ込まれた方には悪いけど、言ってる顔まで浮かんだ
Re: (スコア:0)
publickeyに進行の解説が上がってるから読みなよ
Re: (スコア:0)
たかがsudoをやられただけだまだsuがある。
うろ覚えなんでこんな感じ。
sudo su (スコア:0)
sudoとsuが両方備わり最強に見える
Re: (スコア:0)
まあsuにオプションを付けずにsudoすればubuntuでもsuできる。
確かに最強かもしれない？
Re: (スコア:0)
sudo -i
Re: (スコア:0)
ubuntuでもsu
インストールしてすぐとか、大切なデータもなくroot権限で連続的に操作したいときは、sudo bashってしちゃってるわ・・・
Re: (スコア:0)
sudo -s
Re: (スコア:0)
> もう今日は自分がこれ以上sudoコマンドを実行しない方がいいだろう
こんなときは須藤さんではなく安藤さんの出番ですよね。
# ロバートじゃないよ安藤だよ
Re: (スコア:0)
slコマンドが入ってなくて、タイプミスしてイラっとさせられることが無かったことは幸い。
ライブ配信の動画 (スコア:0)
無事復旧したようでライブ配信のリンク先は現在は終了となっていますが、こちらのURL [youtube.com]から当時の動画が閲覧可能なようです。
って、8時間にわたりひたすらコンソールが写され続け、たまに担当者がなんか話しているという真に誰得な内容ですけど。
…でもTwitterの実況ログ [togetter.com]を見ると、意外と盛り上がっていた様子。なんだこれｗ
＃ 「rm -rf」とか「なんで6MB/sなの？」「staging diskから復旧してるから」とかなんでやり取りしてんだよｗｗｗ
Re: (スコア:0)
昔の２ちゃんねるのように、システムに問題が起きたときに皆がアイディアや技術を出し合って解決していくという手法もいいかもしれない。
どうすれば・・・ (スコア:0)
こういうの聞くと重要なデータを外部に預けるのは恐ろしくて出来ないよな。
管理者が明らかに素人なんだもの。
勿論、内部管理だともっと酷いって現実には目を背けた上での発言ですが・・・
あげくに当人たちは仕事してる気になっているから更に腹が立つ。
自分で管理しだしたら内部統制違反だしなぁ。
Re:どうすれば・・・ (スコア:2)
Google様を信用して重要書類をGoogleDocsにバックアップアップロードしてます。
Google様なら大丈夫だよね？
企業じゃなくって個人のデータだから飛んでも被害はしれてるけど。
Re: (スコア:0)
iPadを寝るときも枕元に離さずどうぞ。
Re: (スコア:0)
データは消えないけど中身を解析されてるかもよ
Re:どうすれば・・・ (スコア:2)
明らかに素人の外部サービスではなくて、S3とかDynamoへリージョン分けてデータ入れるとかが良いと思います。
3箇所へ分けるとか、信頼できないとか・・・古い考えは捨てましょう。
Re:どうすれば・・・ (スコア:1)
会社のデータの管理なんて内部統制とかなんとか言ってる連中の指示する程度にやっておけば十分。
それで消えたらしょうがない、しょせんその程度の価値のデータでしかないんだから。
責任は上司と役員と株主に取らせれば無問題。それが彼らの仕事なんだから。
もしそれで済まないというなら、データの心配する前に、
自分の人生、会社に預けすぎてないか心配しなくちゃ
Re:どうすれば・・・ (スコア:1)
理屈も法的にも確かにそうなんだけどね。
実際事故が起こらないことを祈りつつ指示される通りにしてるわけで。
でも、顧客や他に対して責任もって仕事したいもんじゃないか。
だから紋々とじゃない悶々とするんじゃない。
Re: (スコア:0)
外部に預ける場合、最低３か所に預けるようにすればいいと思うよ。
もちろん暗号化してね。
完璧という保証があるサービスなんてないので、一か所を信じるのは危険。
まあデータの保存だけの話で、コードの管理を委託したいなら無理なんだけど。
どうしてもやりたいなら、３つのサービスを契約して、ラッパーをかませて一か所にコミットしたら、三ケ所にコミットされるようにするとか。
Re: (スコア:0)
それだとバックアップにはならない。ミラーリングをどう実現するかにもよるが間違えて削除したあと削除処理がミラーにも...
バックアップを別の業者のストレージにするだけで大抵は十分。
Re: (スコア:0)
＞間違えて削除したあと削除処理がミラーにも...
どこのファーストサーバだよｗ
http://www.nikkei.com/news/print-article/?R_FLG=0&bf=0&ng=DGXN... [nikkei.com]
ああ、ｂｔｒｆｓがちゃんとしていれば (スコア:0)
スナップショットから戻せばよいのだが。いつまで待てばよいのだ。
Re: (スコア:0)
SUSE Linux Enterprise Serverおススメってくらいだからいける気はする。
そういう仕事はしていないのでどうかは知らんが。
あとLVMでスナップショットとるとかハイパバイザでスナップショットとるとか。