「GitLab.comが誤って本番DBを削除、バックアップも取れていなくて大騒ぎに」記事へのコメント

バックアップの正常動作のチェック

[Anonymous Coward]

本番を間違って削除したことは誰にでも起こり得ることにしても、5系統ものバックアップを持っていながら、それが正しく動いているか（また記録は正常なのか）たまにでもチェックしていなかった事のほうがより重大なミスだと思う。

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

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

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

Re:

[Anonymous Coward]

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

Re:バックアップの正常動作のチェック

[Anonymous Coward]

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

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