バックアップが・・・!! [事例]
データベースの仕事をやっているとたまに出くわすデータ破壊。
主に理由はストレージの故障(特にコントローラ周り)がメインですが、
そのときに大切なのがバックアップ。
普段からバックアップは「ちゃんと」運用していますか?
この「ちゃんと」はとても難しいというお話。
とある重要データを扱うシステム。
最もRDBMSに入っているデータで重要でないものの方が珍しい訳で。
当然バックアップ運用が組み込まれていました。
やり方はよくあるオンラインバックアップをテープライブラリに吸い上げる方式。
幸い安定稼働し続け、ユーザさんには迷惑をかけることなく動いていました。
が、ある日。
そのデータベースが使っていたディスクが多重障害にはまってしまい、ファイルシステムが壊れました。
救えたデータもあったようですがシステム系ファイルが致命的な状態に陥っています。
そこで管理者はバックアップからの戻しを決意しました。
とは言っても手順も標準化されており、スクリプトベースで戻すことができるはずです。
リストア作業を続けています・・・!?
何度戻しても何度リカバリをかけても問題となっているデータベースファイルの
ヘッダが壊れている!!
何が問題なんだろうと管理者は以下のことを行いました。
1.戻したデータファイルの中身をバイナリダンプしてみる
2.バックアップソフトが残しているログファイルを読む
1の結果から確かにおかしなデータがあちこちに書き込まれているようでデータファイルは
正常ではないことがわかりました。
一方2ではテープの読み書きでのエラーは一切起こっていなかったのです。
ですがさっきまで安定稼働していたデータベースとは全く違うデータが
テープには保存されていたのです。
そこでまず取りかかったのがデータ復旧。
そのときは本当にラッキーで、数日前たまたま開発データベース作成のためにデータを
CSV形式でエクスポートしてあったのです。
そこでデータベースを作り直して数日前のデータを入れ、失われた文は帳票から直接再投入しました。
これでデータベースは正常可動可能となりました。
一方でなぜバックアップファイルが壊れていたのか。
これはハードウェアの専門家を入れ協議した結果、テープの寿命であることがわかりました。
実は安定可動時期が長すぎて、その間塩漬け状態となっており、テープの交換がされていませんでした。
正確にはクリーニングテープは交換していたのですが、肝心のデータ用テープは寿命を越えていたのです。
<教訓>
メディアの寿命もちゃんとバックアップ運用で考慮に入れよう
時々でいいからバックアップを違う環境に戻してみて正常性を確認しよう
バックアップは戻してみないと正しいかどうかがわからない!
SQL Serverを使っていればverify onlyでの確認も出来ますが、何より確実な方法はバックアップを
戻してデータの中身を確認することです。もちろん普段からdbcc checkdbは実行しておきましょう。
可能であれば1日1回、実行しておきましょう
データの整合性を維持するには地道な努力が必要なのです。
http://msdn.microsoft.com/ja-jp/library/ms188902.aspx
http://technet.microsoft.com/ja-jp/library/ms176064.aspx
主に理由はストレージの故障(特にコントローラ周り)がメインですが、
そのときに大切なのがバックアップ。
普段からバックアップは「ちゃんと」運用していますか?
この「ちゃんと」はとても難しいというお話。
とある重要データを扱うシステム。
最もRDBMSに入っているデータで重要でないものの方が珍しい訳で。
当然バックアップ運用が組み込まれていました。
やり方はよくあるオンラインバックアップをテープライブラリに吸い上げる方式。
幸い安定稼働し続け、ユーザさんには迷惑をかけることなく動いていました。
が、ある日。
そのデータベースが使っていたディスクが多重障害にはまってしまい、ファイルシステムが壊れました。
救えたデータもあったようですがシステム系ファイルが致命的な状態に陥っています。
そこで管理者はバックアップからの戻しを決意しました。
とは言っても手順も標準化されており、スクリプトベースで戻すことができるはずです。
リストア作業を続けています・・・!?
何度戻しても何度リカバリをかけても問題となっているデータベースファイルの
ヘッダが壊れている!!
何が問題なんだろうと管理者は以下のことを行いました。
1.戻したデータファイルの中身をバイナリダンプしてみる
2.バックアップソフトが残しているログファイルを読む
1の結果から確かにおかしなデータがあちこちに書き込まれているようでデータファイルは
正常ではないことがわかりました。
一方2ではテープの読み書きでのエラーは一切起こっていなかったのです。
ですがさっきまで安定稼働していたデータベースとは全く違うデータが
テープには保存されていたのです。
そこでまず取りかかったのがデータ復旧。
そのときは本当にラッキーで、数日前たまたま開発データベース作成のためにデータを
CSV形式でエクスポートしてあったのです。
そこでデータベースを作り直して数日前のデータを入れ、失われた文は帳票から直接再投入しました。
これでデータベースは正常可動可能となりました。
一方でなぜバックアップファイルが壊れていたのか。
これはハードウェアの専門家を入れ協議した結果、テープの寿命であることがわかりました。
実は安定可動時期が長すぎて、その間塩漬け状態となっており、テープの交換がされていませんでした。
正確にはクリーニングテープは交換していたのですが、肝心のデータ用テープは寿命を越えていたのです。
<教訓>
メディアの寿命もちゃんとバックアップ運用で考慮に入れよう
時々でいいからバックアップを違う環境に戻してみて正常性を確認しよう
バックアップは戻してみないと正しいかどうかがわからない!
SQL Serverを使っていればverify onlyでの確認も出来ますが、何より確実な方法はバックアップを
戻してデータの中身を確認することです。もちろん普段からdbcc checkdbは実行しておきましょう。
可能であれば1日1回、実行しておきましょう
データの整合性を維持するには地道な努力が必要なのです。
http://msdn.microsoft.com/ja-jp/library/ms188902.aspx
http://technet.microsoft.com/ja-jp/library/ms176064.aspx
コメント 0