パスワードを忘れた? アカウント作成
1998054 story
テクノロジー

間違ってデータベースを削除してしまったらどうする? 121

ストーリー by hylom
手作業の場合はチェック体制を 部門より
あるAnonymous Coward 曰く、

2ちゃんねるのニュース速報(VIP)@2ちゃんねる板で、「30分前に顧客DB消しちゃったけど質問ある?」というスレが立ち話題となっている(ログVIPPER速報)。2ちゃんねるの話題なので真偽は不明だが、バックアップを取っていないデータベースに対し手動で「TRUNCATE TABLE」コマンドを実行してしまった、という話だ(スレ立て主のコメントコメント2)。

削除するテーブルと、削除すべきでないテーブルの名前が似ていたためにうっかり削除してしまったという非常にリアリティのある話で、最終的には別の似たようなデータから再生成、作業をしていたスレ立て主はボーナスカット&1週間の出勤停止ということで決着が付いたという内容だ。

実際、データベースを触る技術者にとっては笑えない話なのだが……。こうならないように対処するのが当然なのだろうが、そのような対応策をとれない場合もあるだろう。こういうミスを防ぐためにはどうすればよいのだろうか?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 痛い目を見るまでは対策の必要性など理解されないんですよ。

    --
    一人以外は全員敗者
    それでもあきらめるより熱くなれ
  • ど忘れ (スコア:3, おもしろおかしい)

    by nox_dot (11614) on 2012年03月08日 19時17分 (#2113875) 日記

    truncate ってどういうコマンドでしたっけ?
    調べるのが面倒なので、ちょっと会社のDBで試してみるか。

  • by Anonymous Coward on 2012年03月08日 11時27分 (#2113421)
    その手の業務に携わる人間が、その状況下から2ちゃんねるにアクセスしてたりする(できている)時点で、どうなのよ?と。

    そんな環境を許す職場に向けて、そもそもバックアップ・・・とか言っても意味ナッシングだと思うよ。
  • まず上司に報告して、DB入ってるサーバーをダウンさせて、上書きされるのを回避。
    そののちに専門業者に復旧委託。

    だろうか。
    この場合は原因がわかっているので、まずは復旧させてからのちほど辞表や転職を考える。

  • 手打ちだとどうしても何回かに一回はミスが出るので「これをダブルクリックしてください」「このボタンを押してください」って指示で大丈夫なようにしている。

    #全部そうするのが理想だけどこれがなかなか……。

    --
    LIVE-GON(リベゴン)
  • 重要な更新は(どんな熟達者でも)二人で確認しながら作業するしかないんじゃないかね。
    出来ればロールバック含めた作業手順を前日までにチェック済みにしとくのがいいけど。

    当日の突発作業については「一人でやらない」を徹底するくらいしか手立てを思いつかないなぁ。

    // バックアップとらずに「tar xvf /home/uneune/work/release/atarasiimono.tar -C /」ってやってしまって障害起こしてもうて
    // マジでチビッた。ひさびさに「やってもうたー!!!!!」って叫んだ…
    // 結局前任者のローカルから古いソースを適用して事なきを得たけど、それが出来なかったらと思うと… (:>^

  • by Anonymous Coward on 2012年03月08日 12時00分 (#2113471)

    「こうならないように対処するのが当然なのだろうが、そのような対応策をとれない場合もあるだろう。こういうミスを防ぐためにはどうすればよいのだろうか?」

    さっぱり何が言いたいのか分からない。
    「こうならないように対処する」というのは「ミスを防ぐよう対処する」ということじゃないのか?
    「そのような対応策をとれない場合」というのは「ミスを防ぐための当然の対応策が取れない場合」ということじゃないのか?
    ミスを防ぐための当然の対応策が取れない場合に、どうやってミスを防ぐか、という話なら、「優秀な人間が慎重に作業を進める」とか「臨機応変に対応する」とか、中身のない話しかできないだろう。

  • by Anonymous Coward on 2012年03月08日 12時00分 (#2113472)

    バックアップから復元するテストまで定期的にやってる会社ってどのくらいあるんだろう。

    バックアップとったつもりになってるだけだったら、笑えないぞ。

  • by deleted user (45276) on 2012年03月08日 12時32分 (#2113506)

    顛末の書き込みを読んだのだけれど、

    結論から言うと、

    ・主任降格&治療費支払い&謝罪
    ・例の先輩が主任に昇格
    ・>>1はボーナスカット&1週間の出勤停止
    と相成りました。

    とりあえず朝社長に呼ばれたので、主任とともに向かうと、「やらかしたのか」と一言。
    詳しく事情を説明すると、「細かいことは分からんが、お前が間違えるくらいだからよほどだったのだろう」とのこと。
    上の処分は情状酌量が入った模様。
    DBについては、別のテーブルに似たようなデータがあったためそれを編集して流用。
    あまり深いことは言えんが、データ流用ができたのもずさんな管理だったことが幸い?
    普通は似たデータを複数箇所に置かんもんな

    あと、今後はデータのバックアップおよび直にSQLを打つときは2人以上での確認などもろもろの運用事項が
    加わりました。

    オペミスでこういった直接的な罰則があるというのが結構驚きなのだけれど、そういうもの?
    オペミスは作業者の責任を追及しない印象が頭の中にあったので。

    # 内容がうそかほんとかはさておき

  • by SNLP (45144) on 2012年03月08日 13時45分 (#2113608)
    これはプログラミングの変数名などにも言えることですが
    テーブルには
    わかりやすく、簡潔かつテーブル構成が想像しやすい
    命名をするよう心がけましょう。
    そうするとこういうミスも減ります。

    ・・・いや、序盤は心がけててもクライアントとのやりとりを通して
    テーブルがポコポコ増加すると
    いつのまにか挫折してるんですよねえ(遠い目)。
  • by Anonymous Coward on 2012年03月08日 11時16分 (#2113408)

    顧客DBのバックアップをとっていないという状況が考えられない。
    個人のミスの前に会社的にどうなのよと。

    • 本番環境のテーブルに対してtruncateかけるってのがよくわからん。ふつーそんなことする?
      似たようなテーブルからデータを再作成って、つまりそのテーブルは不要だったかビューの類で良かったんじゃないの?

      親コメント
    • by Anonymous Coward

      「手作業で全削除してタイプミスしたらどうする?」と心配するのでは無くて、
      「そういうミスが起こらない仕組みを作る」が基本だよな。定期バックアップも含めて。

      定型業務らしいし、せめて前もって作ったスクリプトを実行するようにしていれば、テーブル名の
      タイプミスでついうっかりというのは防げるだろうに。
      #つか普通は手作業でやるんじゃなくてcronで(ry

      そういう点も含めて、やっぱり会社的にかなりアレだし、そういう所で働いている
      人たちなので技術者的もそうとうにアレなんだろう。ほんの2~3年前にバージョン管理も
      使わずにWeb開発やってて、開発サーバー上のが最新版ソースという会社も知ってるので、
      このくらいは想像できるけどさ。

      • Re:そもそもだけど (スコア:3, おもしろおかしい)

        by Anonymous Coward on 2012年03月08日 11時51分 (#2113460)

        > #つか普通は手作業でやるんじゃなくてcronで(ry
        cronで実行すれば大丈夫なんて計画を立てるのは机上のcronです。

        親コメント
      • by t-wata (10969) on 2012年03月09日 18時34分 (#2114606) 日記

        > 「手作業で全削除してタイプミスしたらどうする?」と心配するのでは無くて、
        >「そういうミスが起こらない仕組みを作る」が基本だよな。定期バックアップも含めて。

        「ミスが起こらない仕組みを作る」だけじゃなくて「ミスが起きてもリカバリーできる仕組みを作る」ってのも基本です。
        てかtruncateするのに、直前にバックアップを取らないとか信じられないですね。

        親コメント
      • #つか普通は手作業でやるんじゃなくてcronで(ry

        そもそもクローンを作る段階を cron で実行しろ、と言う事ですな (^w^)
        # ごめん、それが言いたかっただけなんだ。

        --
        fjの教祖様
        親コメント
  • by Anonymous Coward on 2012年03月08日 11時16分 (#2113410)

    > バックアップを取っていないデータベースに対し
    はい解散

  • by Anonymous Coward on 2012年03月08日 11時18分 (#2113411)

    本番DBで危険な作業するときは事前にコマンド作成&複数人でレビューが当たり前
    そして打ち間違えないようにコピペ→ダブルチェック→Enter投下

    さらに言うなら、可能な限り作業前にDB全体のバックアップも取っておく
    そもそも1人(2人?)のイージーミスで重大な事故が起こるような仕組みがおかしい

  • by Anonymous Coward on 2012年03月08日 11時25分 (#2113417)

    > 非常にリアリティのある話

    DBのバックアップとっていないなんてぜんぜんリアリティないです。

    • Re:リアリティなし (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2012年03月08日 11時30分 (#2113425)

      「こんな労働基準法違反の会社が存在するなんて話全然リアリティがないです」と言ってるのと同じ。

      親コメント
      • >「こんな労働基準法違反の会社が存在するなんて話全然リアリティがないです」と言ってるのと同じ。

        ですよねー。残業200時間超で10年勤務して手取り20万なんてあるわけないじゃないですかー

    • by digoh (17917) on 2012年03月08日 11時44分 (#2113446) 日記

      「バックアップを取ってないこと」という今回の作業全体の話ではなく
      「削除するテーブルと、削除すべきでないテーブルの名前が似ていたこと」についての感想でしょう。
      切り分けをちゃんとしないと。

      親コメント
    • by oyajismel (32045) on 2012年03月08日 12時00分 (#2113470) 日記
      DB単体のバックアップがなくても(これもほぼありえんが)、サーバー全体のバックアップから一部復旧とかしますよね。。
      親コメント
    • by Anonymous Coward

      「間違ってハードディスクをフォーマットしてしまったらどうする?」
      って堂々と聞かれても、そりゃもうリカバリ屋に頼むほかないだろう・・・・
      としか言えない脱力感がありますよね

      • by wolf03 (39616) on 2012年03月09日 0時16分 (#2114051) 日記
        昔々のDOSの頃、Lotus1-2-3からcommand.com呼び出すまではいいが、
        そのままformatコマンド実行でCドライブを消し飛ばしてくれる所が希に・・・

        テープから初期状態にリカバリ、formatコマンドをリネームしてbatファイルを
        作成して、その中でAドライブをデフォルトでフォーマットするように仕掛けたなぁ
        親コメント
    • by Anonymous Coward

      ですよ。
      技術者から見ると信じられないかもしれませんが。

      最新パッチなにそれ? ウイルス対策っているの? 金の無駄じゃね? って人たちにバックアップが必要って説得するのは骨が折れるというか、一度喰らわないと分かって貰えないというか。

    • by Anonymous Coward
      夜間なり、週1なりでDB全体のバックアップはとるのが普通。

      truncate たたくにしたって先にexportとるだろ。

      export xxxx

      truncate xxxx
      (xxxx)は貼り付け。

      あるとしたら、
      テスト環境につないでいるつもりでバックアップとらない(<=これもいかんのだが)で
      実は本番環境につないでた。か?
    • by Anonymous Coward

      大きな変更時には作業前にバックアップが基本でしょうにねぇ・・・

  • by Anonymous Coward on 2012年03月08日 11時27分 (#2113422)

    保守/テスト環境上で、事前に手順が正しいことを確認しておく。

    …って、バックアップを取っていないような体制で、そこまで環境を揃えるのは
    無理かなぁ…

  • by Anonymous Coward on 2012年03月08日 11時30分 (#2113426)

    sqlを本番で直叩きするような運用は地雷原でフラダンスを踊っているようなものだし
    クリティカルなことをする前にバックアップを取らないのは、保険をかけずにクルマを運転するようなものだから、事故は必然だったと思う。
    起きるべくしておきた。

    それでも、やらなければというならば、今回のように情報を別のテーブルやアプリログ、その他にもおとすようにしといてそこから頑張って復旧しかないよね。
    そっちのほうが最終的に高くつくから、そうならないように設備投資をケチるなよ、みたいな。

  • by Anonymous Coward on 2012年03月08日 11時33分 (#2113432)

    そもそも、作業ミスに対してこういう懲罰っていいんだっけ?(請求がダメなんだっけ?)
    # ちょっとググったらこんなん [goo.ne.jp]出てきた
    おまけにスレでは

    160 : 以下、名無しにかわりましてVIPがお送りします : 2012/03/06(火) 00:45:13.61 ID:hbMijEhe0 [7/28回発言]
    殴られて歯が折れた
    明日がこわい

    173 : 以下、名無しにかわりましてVIPがお送りします : 2012/03/06(火) 01:09:47.89 ID:hbMijEhe0 [8/28回発言]
    殴ったのは例の設計者である主任だ。
    暴れまくって、俺の歯とサーバ1台を破壊
    今どっか出てった

    とかだし。

  • by Anonymous Coward on 2012年03月08日 11時37分 (#2113439)

    顧客の会社がそのあとどうなったかのほうが気になる。

    データベースの内容によってダメージはピンキリだろうけど、
    最悪、倒産して社長が首つるくらいのことはあるかもしれない。

    • そういえばつい最近、データが戻せずに運営中止になった
      オンラインゲームがありましたね。

      ここがバックアップとってたかどうかは不明ですが、
      場合によってはこういうことも起こりうるってことを思えば、
      やはり日頃のバックアップは大切ですね。

      親コメント
      • by Anonymous Coward

        > データが戻せずに運営中止になった
        > オンラインゲームがありましたね。

        そーゆーのって、最新ピリオドにおいては赤字状態になってて、
        運営側が切り捨てるタイミングを見計らってた、なんて事が多いので、
        データが消えた事によるダメージは無いどころか、
        経営的には赤字を減らすポジティブな結果だったり…

typodupeerror

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー

読み込み中...