パスワードを忘れた? アカウント作成
13142060 story
クラウド

GitLab.comが誤って本番DBを削除、バックアップも取れていなくて大騒ぎに 57

ストーリー by hylom
なぜバックアップが取れていないのだ 部門より
あるAnonymous Coward曰く、

ソースコード管理サービスを提供するGitLab.comが1月31日、管理者の操作ミスにより本番DBのデータ300GBを誤ってディレクトリごと削除してしまい、サービス停止状態に陥ったことが明らかになった(公式報告のGoogle DocPublickeyThe RegisterSlashdot)。

GitLab.comはオープンソースのソースコード/プロジェクト管理ソフトウェアGitLabを使ったホスティングサービスを提供するクラウドサービスで、GitリポジトリやWiki、Issue管理といった機能を提供している。報告によると、同社では31日、スパムユーザーの負荷によりセカンダリDBに異常が発生したことから、セカンダリをクリーンしてからレプリケーションを復旧する作業を実施していたとのこと。しかし作業がうまくいかず、再度セカンダリをクリーンしようとして、誤って残るプライマリをクリーンしてしまったという。同社は直ちにバックアップからの復旧を試みるも、5系統あるはずのバックアップはいずれもエラーなどで実は機能していないという事が判明、一時騒然となった。なお失われたDBはIssueやMergeリクエストのもので、Gitリポジトリ本体とWikiは無傷だという。

その後、たまたま作業の6時間前に取られていたスナップショットが思いだされ、これを元に復旧作業が進められているのだが、タレコミ時点では何故かその様子がYouTubeでライブ配信されるという不思議なことになっている。なおミスを起こしたYP氏は「もう今日は自分がこれ以上sudoコマンドを実行しない方がいいだろう」と語っているという。

  • by Anonymous Coward on 2017年02月02日 18時31分 (#3154764)
    本番を間違って削除したことは誰にでも起こり得ることにしても、5系統ものバックアップを持っていながら、それが正しく動いているか(また記録は正常なのか)たまにでもチェックしていなかった事のほうがより重大なミスだと思う。

    かく言う私自身も、今のように複数系統のバックアップもストレージ多重化もハードウェアの制約と高価なために中小企業では導入が難しかった頃、小規模システムながら更新前バックアップ処理を失敗した状態で年次更新手順を失敗、取りあえず当年度データは無事で次年度データは作成した物の前年度の月次データを丸々紛失、担当者に帳票から再入力で再現してもらい約半年で復旧してもらったという最悪な状況をつくったことがあったから、複数系統のバックアップとその正常性にはいつも気を使うようになったのですが・・・。
    ここに返信
    • by Anonymous Coward on 2017年02月02日 18時42分 (#3154778)

      実際ありがちなんだよな、restoreできないバックアップ処理系になってるパターン
      長く運用されてデータ量増えたりスケールアウト|アップされたのにバックアップ側変更無しで実はトラブってて
      JCLだの死活監視だのからはsuccessに見えてるけどいざそのとき使えないゴミデータがバックアップされてるやつ。

      • by Anonymous Coward on 2017年02月02日 21時14分 (#3154852)

        私も引継ぎマニュアルをみて、ミラーリングとバックアップサーバありね、ふんふん…と見ただけで流しちゃって
        その翌月、年次点検で電源落とした時に見事にクラッシュ
        ミラーリングのはずのHDDは1つしか刺さっておらず、バックアップは数年前
        月額制のブラウザゲーなので壊れちゃいましたゴメンナサイは出来れば避けたいというかヤバイ
        メンテの為停止しますとなってから復旧しないため、2chにデータとんだんじゃね?って書かれるしまつ!
        結局復旧業者で何とか直ったけど一週間止まったよ

        手順あっても実際に確認はほんと大事
        バックアップ終了メールきててもメール文面をみないとか

        • by Anonymous Coward on 2017年02月02日 22時21分 (#3154897)

          > 年次点検で電源落とした時に

          法定点検で電源落としたら再開時にネットに接続できなくなって、原因調べたらISPへの料金滞納が発覚したというひどい話もあったな。フレッツはISP側から回線切断することができないのでこっちから切るまで発覚しないらしい。

          • by Anonymous Coward

            ああやっぱり回線って強制切断は出来ないのか
            学生時代にアレでアレな事をしている時にISPへの接続がbanされる時でも接続中なら大丈夫だった事がある と聞いた

        • by Anonymous Coward

          確認も大切だが復元テストも大事

          • 実際に復元テストしようにも、テスト用の復元先環境なんか、オンプレミスだと用意して貰えないって事の方が多い気がする。

          • by Anonymous Coward

            あるある・・・

          • by Anonymous Coward

            SEしてた頃、しなかったな…復元テスト…。
            もし失敗したら、また1から環境の作り直し。確実に納期に間に合わない!
            先輩に「これほんとにリストアできるんですかね?」と聞いたら、
            「さあ?」という答えだったのが今でも忘れられない。

            • by Anonymous Coward

              そんな時嘘でもたぶんといえるそんな優しい人に私はなりたい

          • by Anonymous Coward

            復元テストといえば
            MySQLのバックアップが作られていた環境で
            バックアップの手順として、OSコマンドでフォルダをコピーという形で取得されていたんだけど
            止めずにコピーしていたので、復元できるかテストをしたらやっぱり壊れてた

            壊れたデータを取ってる可能性があるので、見直しはほんとだいじ

    • by Anonymous Coward on 2017年02月02日 19時01分 (#3154786)

      保守費を貰って無い会社でバックアップの設定だけしてその後はノータッチの場合、トラブルが起きてバックアップから戻してくれと依頼されてバックアップを見たら、きちんと取れてない事がよくある。むしろ、きちんと取れてた事の方が珍しい。

      自社運用でも、きちんと担当者を決めたり工数を確保したりしとかないと、今回のように設定したまま誰もチェックしない放置状態になるんじゃないかな。

    • by Anonymous Coward on 2017年02月02日 18時37分 (#3154772)

      待機系があるなら定期的に待機系に復元して運用系と切り替えしてみる(つまり平時から運用に組み込む)のが確実ですね。

    • by Anonymous Coward

      そういうのはお家のお宝画像のバックアップに失敗したときに覚えた。
      確かDVDにバックアップしたのだがデータが化けていて…
      別にピンク色なあれではなく映画の壁紙だとかそんなもの。

    • by Anonymous Coward

      重大なミスというのは重なるものです。ハインリッヒの法則ですね。

      • by Anonymous Coward

        これで担当者責められるとしたら、その組織管理者にダメ判定下しますね。
        システム(バックアップ)ミスをカバーするために、想定外のことをやってる状態なので。

        この場合「どうでも良いから何とかしろ」的に急かすのも同罪。

        • by Anonymous Coward

          とりあえずGitlabについて言えば、今回の件を理由に処分される従業員はいないと語っているようです。

  • by Anonymous Coward on 2017年02月02日 19時16分 (#3154794)

    随時報告されるとあまり怒りを感じないのと同じでしょうか

    # でも目を背けずにはいられなかった

    ここに返信
  • ファーストサーバよりましだわな。
    機能してないにしても。

    しかし、なぜ一連のファーストサーバのストーリーが関連リンクにないのだろう。
    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]

    ここに返信
  • by Anonymous Coward on 2017年02月02日 18時40分 (#3154777)

    各利用者のローカルにクローンが残ってるだろうからまだ良かったのにね。

    # そういう話ではない

    ここに返信
    • by Anonymous Coward

      実際Issueぶっとばされるのは結構キツいよね。

      リポジトリのissueディレクトリに実体があるようなシステムだったら便利かなあ。検索とか。

  • by Anonymous Coward on 2017年02月02日 19時21分 (#3154796)

    > もう今日は自分がこれ以上sudoコマンドを実行しない方がいいだろう

    担当者を晒したり、対外的に愚痴をこぼしたり、ちょっと理解不能な集団だな。
    サイトTOPに社員らしき顔写真晒してる時点で十分イカレてるけど。

    そもそも、DBのクリーニングとディレクトリ削除の因果関係が不明だし、レプリケーション状態のセカンダリだけを操作するって発想が理解できないんだけど。
    DB管理上の問題があるんじゃねーのかな。

    ここに返信
    • by Anonymous Coward on 2017年02月03日 10時08分 (#3155083)

      それを「晒し」と感じた時点でもう負けじゃないですかね。
      この人たちは最初から「この件で解雇される従業員は絶対にいません」と断言していましたし、
      険悪なムードにももならずに淡々と顔出しで復旧作業を続け、その経緯をリアルタイムで公開していましたし、
      逆に魅力的な会社だと思った人の方が多いんじゃないでしょうか。

      バックアップが間違っていた件は擁護できませんが、その原因を誰に言われるでもなく全部公開しており、
      透明性がありすぎてこちらが心配になるくらいでした。
      こんなに内部事情を公開して大丈夫かという懸念に対しても「security by obscurityなんかに頼りません、
      この作業ログを晒すことで脆弱になるとは思っていません」と力強く発言する感じとか、ちょっとカッコ良かったです。
      (まあソフトウェア自体オープンソースですし)

    • by Anonymous Coward on 2017年02月02日 22時13分 (#3154890)

      > もう今日は自分がこれ以上sudoコマンドを実行しない方がいいだろう

      ここは笑ったけど、自分から言いだすのは確かに文化の違いかなぁ
      他人に言ってあげたことはあるけど・・トラブって正常な判断が出来なくなってる人に対応させても良いことないからね。

      でも日本の組織だと、凹んだやつを見つけるとここぞとばかりに叩く上司が多いんだよな
      技術力がない人が上司になって、すべての責任を部下にって、よく見かけたなぁwww

      • by Anonymous Coward on 2017年02月02日 23時33分 (#3154921)

        >> もう今日は自分がこれ以上sudoコマンドを実行しない方がいいだろう

        >ここは笑ったけど、自分から言いだすのは確かに文化の違いかなぁ

        笑うどころか、とても賢明な判断と思えました。
        もし君がこれを言い出せない文化にいるなら脱出をお勧めする。いや実際、君のためになると思う。

    • by Anonymous Coward

      publickeyに進行の解説が上がってるから読みなよ

    • by Anonymous Coward

      たかがsudoをやられただけだまだsuがある。
      うろ覚えなんでこんな感じ。

      • by Anonymous Coward

        sudoとsuが両方備わり最強に見える

        • by Anonymous Coward

          まあsuにオプションを付けずにsudoすればubuntuでもsuできる。
          確かに最強かもしれない?

          • by Anonymous Coward

            sudo -i

          • by Anonymous Coward

            ubuntuでもsu

            インストールしてすぐとか、大切なデータもなくroot権限で連続的に操作したいときは、sudo bashってしちゃってるわ・・・

    • by Anonymous Coward

      > もう今日は自分がこれ以上sudoコマンドを実行しない方がいいだろう

      こんなときは須藤さんではなく安藤さんの出番ですよね。

      # ロバートじゃないよ安藤だよ

    • by Anonymous Coward

      slコマンドが入ってなくて、タイプミスしてイラっとさせられることが無かったことは幸い。

  • by Anonymous Coward on 2017年02月02日 19時59分 (#3154819)

    無事復旧したようでライブ配信のリンク先は現在は終了となっていますが、こちらのURL [youtube.com]から当時の動画が閲覧可能なようです。
    って、8時間にわたりひたすらコンソールが写され続け、たまに担当者がなんか話しているという真に誰得な内容ですけど。

    …でもTwitterの実況ログ [togetter.com]を見ると、意外と盛り上がっていた様子。なんだこれw

    # 「rm -rf」とか「なんで6MB/sなの?」「staging diskから復旧してるから」とかなんでやり取りしてんだよwww

    ここに返信
    • by Anonymous Coward

      昔の2ちゃんねるのように、システムに問題が起きたときに皆がアイディアや技術を出し合って解決していくという手法もいいかもしれない。

  • by Anonymous Coward on 2017年02月02日 21時15分 (#3154853)

    こういうの聞くと重要なデータを外部に預けるのは恐ろしくて出来ないよな。
    管理者が明らかに素人なんだもの。

    勿論、内部管理だともっと酷いって現実には目を背けた上での発言ですが・・・
    あげくに当人たちは仕事してる気になっているから更に腹が立つ。
    自分で管理しだしたら内部統制違反だしなぁ。

    ここに返信
    • by tarna (10845) on 2017年02月03日 0時49分 (#3154948) 日記

      Google様を信用して重要書類をGoogleDocsにバックアップアップロードしてます。
      Google様なら大丈夫だよね?
      企業じゃなくって個人のデータだから飛んでも被害はしれてるけど。

      • by Anonymous Coward

        iPadを寝るときも枕元に離さずどうぞ。

      • by Anonymous Coward

        データは消えないけど中身を解析されてるかもよ

    • 明らかに素人の外部サービスではなくて、S3とかDynamoへリージョン分けてデータ入れるとかが良いと思います。
      3箇所へ分けるとか、信頼できないとか・・・古い考えは捨てましょう。

    • by Anonymous Coward on 2017年02月02日 22時13分 (#3154888)

      会社のデータの管理なんて内部統制とかなんとか言ってる連中の指示する程度にやっておけば十分。
      それで消えたらしょうがない、しょせんその程度の価値のデータでしかないんだから。
      責任は上司と役員と株主に取らせれば無問題。それが彼らの仕事なんだから。

      もしそれで済まないというなら、データの心配する前に、
      自分の人生、会社に預けすぎてないか心配しなくちゃ

      • by Anonymous Coward on 2017年02月03日 1時46分 (#3154965)

        理屈も法的にも確かにそうなんだけどね。
        実際事故が起こらないことを祈りつつ指示される通りにしてるわけで。

        でも、顧客や他に対して責任もって仕事したいもんじゃないか。
        だから紋々とじゃない悶々とするんじゃない。

    • by Anonymous Coward

      外部に預ける場合、最低3か所に預けるようにすればいいと思うよ。
      もちろん暗号化してね。
      完璧という保証があるサービスなんてないので、一か所を信じるのは危険。
      まあデータの保存だけの話で、コードの管理を委託したいなら無理なんだけど。
      どうしてもやりたいなら、3つのサービスを契約して、ラッパーをかませて一か所にコミットしたら、三ケ所にコミットされるようにするとか。

      • by Anonymous Coward

        それだとバックアップにはならない。ミラーリングをどう実現するかにもよるが間違えて削除したあと削除処理がミラーにも...
        バックアップを別の業者のストレージにするだけで大抵は十分。

  • by Anonymous Coward on 2017年02月03日 7時54分 (#3155005)

    スナップショットから戻せばよいのだが。いつまで待てばよいのだ。

    ここに返信
    • by Anonymous Coward

      SUSE Linux Enterprise Serverおススメってくらいだからいける気はする。
      そういう仕事はしていないのでどうかは知らんが。
      あとLVMでスナップショットとるとかハイパバイザでスナップショットとるとか。

typodupeerror

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

読み込み中...