ドキドキ！サーバー上で誤って削除されたデータの回復プロセス

2日間の絶え間ない努力の末、誤って削除された本番サーバーのデータをようやく回復できました。この事故の過程と解決法は、私自身に警告し、他の人にこの間違いをしないように思い出させるためにここに記録されています。また、問題に遭遇した友人たちが、その問題を解決するためのインスピレーションを見つけられることを願っています。

背景

ある女子生徒が、本番サーバーに Oracle をインストールする任務を負いました。彼女は Oracle の勉強とインストールを同時に行いましたが、インストールが正しくないと感じたため、アンインストールして再インストールする準備をしました。インターネットでアンインストール方法を見つけましたが、Oracle インストール ディレクトリを削除するにはコマンド ラインを実行する必要がありました。コマンドは次のとおりです。

rm -rf $ORACLE_BASE/*

ORACLE_BASE変数に値が割り当てられていない場合、コマンドは

rm -rf /*

==||、女の子はルートアカウントを使用しています。このようにして、アプリケーション Tomcat、MySQL データベースなど、ディスク全体のすべてのファイルが削除されました。 。 。 。

(MySQLデータベースは動いていないのでしょうか？Linuxは実行中のファイルを削除できるのでしょうか？いずれにしても完全に削除され、tomcatのログファイルが残っていました。ファイルが大きすぎてしばらく正常に削除されなかったと推測されます。)

少女の自責の念にかられた目を見ると、私が彼女にこのことをするように仕向けたのであって、彼女に事の重大さを説明しなかったからだ。訓練も受けていないので、責任は一人しか負えない。それに、どうして美しい女性にこの責任を負わせられるだろうか？

コンピュータ室に連絡し、別のサーバーにディスクをマウントしてsshで接続して確認したところ、すべてのファイルが消去されていました。このサーバーは顧客の本番システムで稼働しており、半年以上稼働していたため、早急に復旧する必要がありました。そこで、データベースのオフライン バックアップを探してみたところ、バックアップ ファイルはわずか 1 KB で、mysqldump のコメントの見慣れた行が数行だけ含まれていることがわかりました (crontab によって実行されたバックアップ スクリプトに何か問題があったのでしょうか)。最新のバックアップは 2013 年 12 月のものでした。まさにダブル パンチでした。

あるリーダーが話してくれたある事例を思い出しました。本番システムがクラッシュした際に、すべてのバックアップに問題があり、焼いた CD に傷があり、テープ ドライブが壊れていたことが判明しました (業界の先輩で、以前はバックアップに CD を使用していたようです)。今日、本当に自分に起こるとは思いませんでした。どうすればよいでしょうか。

部門リーダーは状況を知った後、すでに最悪の場合のプラン B を立てていました。つまり、リーダーは日曜日にチームと製品 AA を率いて顧客がいる都市に直接赴き、月曜日に経営陣と連絡を取り、BB と CC は顧客管理者のもとへ行き、顧客を説得する方法を探しました。 。 。

命を救うストロー - ext3grep

誤って削除したデータを復元する方法に関する情報をすぐにオンラインで検索し、rm -rf で削除されたファイルを復元できる ext3grep を見つけました。私たちのディスクも ext3 形式であり、インターネット上には成功例が多数あります。そこで一筋の希望の光が灯り、私はすぐにディスクをアンマウントして、ファイルを追加または削除するセクターが書き換えられないようにしました。 ext3grep をダウンロードしてインストールします (コンパイルとインストールのプロセスは難しいですが、今は詳細には触れません)。

まず、ファイル名をスキャンするコマンドを実行します。

ext3grep /dev/vgdata/LogVol00 --dump-names

削除されたファイルとパスがすべて印刷され、私は大喜びしました。ファイルはまだ残っていたので、プラン B を実行する必要はありませんでした。

このソフトウェアはディレクトリごとにファイルを復元することはできず、restore all コマンドのみを実行できます。

ext3grep /dev/vgdata/LogVol00 --restore-all

その結果、現在のディスク容量が不足しているため、ファイルを復元するしかありません。いくつかのファイルを試しましたが、成功したものもあれば、失敗したものもありました。

ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/aqsh/tb_b_attench.MYD

思わず胸が熱くなりました。ディスクに書き込まれたファイルが削除されてしまったのでしょうか? 復旧できる可能性は低いでしょう。とにかく、できる限り復旧を試みます。もしかしたら、重要なデータファイルは復旧可能な MYD ファイルにあるかもしれません。まずすべてのファイル名をファイルにリダイレクトします

ext3grep /dev/vgdata/LogVol00 --dump-names >/usr/allnames.txt

すべてのmysqlデータベースファイル名をフィルタリングし、mysqltbname.txtとして保存します。

ファイルを復元するスクリプトを作成します。

•  
  • LINEを読みながら
  • する
  echo "ファイルの復元を開始します" $LINE
  ext3grep /dev/vgdata/LogVol00 --restore-file $LINE
  [ $? != 0 ] の場合
  それから
  echo "復元に失敗しました。終了"
  # 終了 1
  フィ
  • 完了 < ./mysqltbname.txt

実行に約20分かかり、40以上のファイルが復元されましたが、それだけでは十分ではありませんでした。テーブルは100近くあり、各テーブルにはfrm、myd、myiの3つのファイルがあります。少なくとも300以上のファイルがあります！復元したファイルを既存のデータベースに添付し、ファイルの権限を777に設定して、MySQLを再起動します。一部のデータは復元されましたが、顧客の重要な勤怠データと携帯電話のレポートデータ（顧客はこれらのデータを使用して従業員のパフォーマンスを計算しているとのこと）はまだ復元されていません。

どうすればいいでしょうか？ extundelete という別のツールを試してみましたが、これは基本的に ext3grep と同じ構文で原理は同じはずですが、ディレクトリ単位で復元できるとのことなので試してみました。

/dev/vgdata/LogVol00 を削除 --restore-directory var/lib/mysql/aqsh

予想通り、ファイルは復元できませんでした!!!!!!! ファイルは破壊されました。上司に報告し、プラン B を実行します。 。 。仕事が終わったら家に帰るしかありませんでした（週末なので帰って休んで解決策を考えます）

突然のひらめき: binlog

翌朝、私は（何か思いついたことがあって）早く起き、パソコンを持って会社に行きました（批判もされず、通知もされず、罰金も解雇もされなかっただけで十分だったので、この週末は台無しになったとみなされました。週末を過ごす意味なんてどこにあったのでしょう）。

ext3grep と extundelete をまだ実行していますが、いくつかのトリックがあります。システムをテスト サーバーに配置して、データを修復する方法があるかどうかを確認します。テスト サーバーで mysqldump を実行し、ファイルを復元し、復元したファイルを上書きし、ファイルに権限を追加して、mysql を再起動します。

ちょっと待ってください、binlog はないのですか? 当社のサービスはすべて binlog を有効にする必要があるので、binlog からデータを回復できるかもしれません。

そこで、ダンプファイル名からbinlogファイルを見つけました。合計3つあります。mysql-binlog0001、mysql-bin.000009、mysql-bin.000010、復元された0001です。

ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/mysql-bin.000001

実際には失敗しました。 。 。 。 。 。

他の2つのファイルを見ると、mysql-bin.000010 は数百MB程度なので、こちらの方が信頼性が高いはずです。復元コマンドを実行したところ、成功しました!!!!!!!!!!!!!!!

すぐにテストサーバーに scp します。 binlog の復元を実行します。

mysqlbinlog /usr/mysql-bin.000010 | mysql -uroot -p

パスワードを入力したら、スタックしてしまいました（良い兆候です）。長い間待った後、ようやく終了しました。アプリを開くと、ああ、CCTV、MTVのおかげで、データが戻ってきました!!!!!!!!!!!!!!!

追記

この事故の後、幸運にもデータは回復されましたが、その過程はスリリングなものでした。私はまた、自分のミスがもたらす結果と、同僚や上司に与える連帯責任を恐れています。また、この事故を忘れず、今後同じ過ちを繰り返さないよう願っています。事故の反省は次の通りです。

1. MM にサーバーのメンテナンスを依頼した際、深刻な状況が事前に説明されておらず、私も真剣に受け止めなかったため、管理やプロセスが混乱しました。オンライン生産システムでは、変更は実装前に計画する必要があります。

2. 自動バックアップに問題が発生しましたが、誰もそれをチェックしませんでした。オフライン バックアップ担当者は、毎回サーバーから 1k 個のファイルをダウンロードしますが、まったく注意を払いません。職場では全員の責任を明確にする必要があります。

3. 事故後、発見が間に合わなかったため、一部のデータがディスクに書き込まれ、回復不可能な問題が発生しました。サービスに異常が発生した場合に、関係する担当者に SMS で通知されるように、アプリケーション監視プログラムを作成する必要があります。

コメントに従って、もう 1 つ追加します。

4. 操作にはrootユーザーは使用できません。異なる権限レベルを持つユーザーをサーバー上に設定する必要があります。

この事故を通じて、このプロジェクトや事故とは何の関係もない同僚数名が協力し、情報を調べ、テストを手伝ってくれました。同僚の 1 人は、午前 1 時過ぎまでデータ復旧テストを手伝ってくれました。同時に、顧客からの大きなプレッシャーを考えたとき、プロダクトマネージャーはパニックに陥って開発者やオペレーターを責めるのではなく、全員が落ち着いて解決策を考えられるようにしました。部門リーダーたちも率先して解決策を見つけ、私たちと一緒に残業してテストし、物事の進行状況をリアルタイムで追跡してくれました。

全員の共同の努力により、この問題は最終的に比較的満足のいく形で解決しました。次は月曜日の朝に全員で振り返り、経験と教訓を総括します。このような事故が起こらないように最善を尽くさなければなりません。

ポータル

この記事で使用されているツールへのリンク:

1.ext3grep:https://code.google.com/p/ext3grep/

コンパイルとインストールには多くの依存パッケージがあります。インストール方法についてはオンラインで検索できます。著者が提供したハウツーがブロックされているのは残念です。私は壁を乗り越えてハウツーの PDF ドキュメントをダウンロードしました。これを読めば、Linux ファイルシステムについてより深く理解できるようになります。ハウツーをダウンロードしてください (http://pan.baidu.com/s/1kT1ETVp)。

このツールにはバグがあります。エラー発生後、ext3grep は下方向に実行されません: init_directories.cc:534: void init_directories(): Assertion `lost_plus_found_directory_iter != all_directories.end()' failed.、リカバリに失敗します。作者がパッチを公開しています。ダウンロード アドレスは、パッチ ダウンロード (https://ext3grep.googlecode.com/issues/attachment?aid=3222478933841854269&name=lostfound_missing.patch&token=ABZ6GAfPeDpgvmC7lK0tdcQCktSl6-dODw%3A1400329392182) です。作者がなぜこのパッチを新しいバージョンに追加しなかったのか理解できません。

2.extundelete: http://extundelete.sourceforge.net/

機能は ext3grep に似ており、原理も同様であるはずです。ディレクトリを復元できると主張しているだけですが、成功したことはありません。

原題: ドキドキ!サーバー上で誤って削除されたデータの回復プロセス

キーワード: