削除された後の努力を不断の二日間を経験し、最終的に本番サーバのデータの不正使用を再開しました。
このレコードでの事故やソリューションのプロセスは、自分自身を警告とMoを示唆して他の人はこのミスを犯しました。
私は友達が直面する問題は、問題を解決するためのインスピレーションの痕跡を見つけることができます願っています。
01 事故の背景には
、Oracleが本番サーバにインストールされている姉を配置し、姉妹エッジ研究側のインストールは、インストール、アンインストール再インストールする準備ができて感じることはありません。
次のようにOracleのインストールディレクトリのコマンドラインを実行するためにインターネット、削除からアンインストールして下さい、コマンドは次のとおりです。
RM -高周波$ ORACLE_BASE / *
ORACLE_BASE変数が割り当てられていない場合、コマンドは次のようになります。
RM - RF / *
そしてその上で、私の妹は、rootアカウントああを使用しました。このように、ディスク全体は、Tomcat、MySQLデータベースSO ON ......とのアプリケーションを含む、すべてのファイル、削除
MySQLデータベースが実行されていませんか？Linuxはそれが完全に除去されているので？実行されているファイルを削除し、最後にログファイルのTomcatを左にすることができ、ファイルが大きすぎると推定、そして時には正常に削除されません。
姉妹後悔の目を見て、それはどんなトレーニングなしで、負債は一人だけバックすることができ、賭け金は明確な彼女に言うと、それ美しいクマこの責任を作成する方法のほかになかった、彼女が何をするために私が配置されたのはこの事です？
部屋への呼び出しは、別のサーバーにディスクをハングアップする、すべてのファイルが消去されたSSH回復基調ビュー、このサーバが実行されているが、顧客の生産システムは、ああ、6ヶ月間実行されている、早くああなどとして復元されました。
そして、コメントおなじみのmysqldump（クローンタブが問題に実行されたバックアップスクリプト）の唯一の数行でバックアップファイルのみ1キロバイトを、見つける、データベースのオフラインバックアップのために送られ、最寄りのバックアップは本当にリーキー家の2013年12月であり、毎晩雨ああ。
それを考えるリーダーの場合は、言った：生産システムがハングアップすると、すべてのバックアップは、DVDにも傷があり、テープドライブも（悪いシニア産業である、以前の推定値は、バックアップCD-ROMを行う質問がある見つけます）、私はどのように、本当に私の体を成就するために期待していませんでしたか？
事態を知っ部門長の後、最悪の事態はプランBに行われました：製品のリーダーシップと顧客がリーダーシップの通信に月曜日市に駆けつけ個人的につながっAA日曜日、BBおよびCCは、顧客の管理者に方法を見つけるためにあそこに行きます......顧客を説得
02 ：わらext3grep、RM -rfによって、私たちも、ext3のディスクフォーマットを削除し、オンライン本当にext3grepファイルを回復できます、情報を見つけるためにオンラインで行くために急いでは、誤ってデータの回復を削除しました多くのサクセス・ストーリー。
そうは削除されたファイルの部門を作るために再書かれを防ぐために、できるだけ早くディスクのumountのように、かすかな望みを燃やし。ダウンロードext3grep、インストール（コンパイルして当面骨の折れるプロセスをインストールすると、表ではありません）。
最初のスキャンファイル名のコマンドを実行します。
ext3grep / DEV / vgdata / LogVol00 - ダンプの名前
すべて削除されたファイルとパスをプリントアウトし、喜び、プランBを実行せずに、ファイルがそれです。
このソフトウェアは、ディレクトリでファイルを復元することができ、すべてのコマンドは、リカバリを実行することができます。
ext3grep / DEV / vgdata / LogVol00 - 復元、すべての
ディスクスペースの現在の不足、決しての結果はファイルのみを復元することができ、いくつかのファイルが、それでも部分的に成功した部分的な障害を試してみてください。
ext3grep / DEV / vgdata / LogVol00 ファイルを復元するの/ var / libに/ mysqlの/ US tb_b_attench.MYD
あなたはそれがディスク上のファイルを削除するように書かれていたが、寒さを助けることができませんか？回復の可能性はない、ああ、あなたはいくつかのカウントを復元することができますいくつか、多分ちょうど重要なデータがMYDファイルをファイルを復元することができます。
だから、最初にすべてのファイル名のファイル内のファイルにリダイレクト：
ext3grep / DEV / vgdata / LogVol00 - ダンプ名> /usr/allnames.txt
mysqltbname.txtとして保存されているすべてのMySQLデータベースのファイル名を除外する。
スクリプトは、ファイルを回復します：
一方、 読み取りLINE 行う "エコーを開始 するために 、復元 ファイルを$ LINE" ext3grep / devの/ vgdata / LogVol00 - リストアファイル$ LINE 場合は [ $を？！= 0 ] その後、 "エコーリストアが失敗し、終了" ＃1 の出口 1 Fiあり なさ<。/ mysqltbname.txt
実行、20分程度の実行、40以上のファイルの回復ではなく、十分なああ、我々は詳細300ああよりもそこにあると言ってどのように、ほぼ100テーブル、各テーブルのFRM、MYD、MYI 3つの文書を持っています！
これらのデータは、顧客が言われている（既存のデータベースに添付されたファイルを戻ってきて、だけでなく、データバックの一部とみなすことができる777へのファイルのアクセス権、再起動のMySQLに、しかし、顧客が出席データ、データの電話側の報告に署名することが重要であるだろうああ戻ってきていない従業員のパフォーマンスを）行います。
することになって？ext3grep文法で、別のツールのextundeleteを試みた中東と基本的に同じ原理は同じである必要がありますが、ディレクトリで復元すると言われています。
まあ、それを試してみます：
extundelete / DEV / vgdata / LogVol00 - 復元ディレクトリ/ var / libに/ mysqlの
右合図に、回復は出てきません！！！！！！！！これらのファイルが破壊されました。仕事からの報告、計画Bの実装は今......絶望の家のリーダーシップを持ちます。（週末は、方法を考える、戻って休憩を取る）
03は、アイデアを持っていた：BINLOG
翌朝は早朝に目が覚めた（心の問題ああ）、コンピュータの背面には、会社に行く（この週末は、払い戻し批判しない、知らされ、罰金、良い上の解雇が、また、どのような週末ああ）。
まだテストサーバーラック・システムに配置しますext3grep、extundelete、ああレシピを実行し、それを修理する方法を見つけるために、データを見ることができます。
テストサーバーのmysqldumpで行われ、ファイルを復元、ファイルの裏表紙を回復する、ファイルへのアクセス権を追加し、再起動のMySQL。
待って、待って、BINLOGことありませんか？当社のサービスは、多分あなたはそれでデータBINLOGを回復することができ、バイナリログを開くために必要とされていますか？
だから、3の合計のうち、ファイル名からBINLOGダンプファイルを検索します：
- MySQLの-binlog0001
- MySQLの-bin.000009
- MySQLの-bin.000010
0001についての復元：
ext3grep / DEV / vgdata / LogVol00 - 復元ファイルをVAR / libに/ mysqlの/ mysqlの-bin.000001
実は......他の2つのファイルのmysql-bin.000010を見て、おそらく数百MBに失敗し、restoreコマンドを実行し、実際に成功少しトリッキーする必要があります！
すぐにテストサーバーにできるだけSCP。実行BINLOG復元します：
mysqlbinlogは/ USR / mysqlの- binに。000010 | mysqlの- uroot - P
長い待ち時間が最終的に終わった後、パスワード、スタック（良い記号）を入力します。アプリケーションを開き、ああ、CCTV、MTV、データバックに感謝！
04 ポストスクリプトは
また、もはや同じ間違いをしないだろう、心の中で事故を維持したいです。反射事故は次の通り：
- 彼らはより悪い状況を説明し、彼は、混乱管理にプロセスの混乱を重視していなかったこのサーバメンテナンスMMの彼女の時間を手配するために進めませんでした。オンライン生産システムは、すべての変更は、最初に計画してから移動する必要があります。
- 自動バックアップの問題、誰かどうかをチェックします。オフラインバックアップ要員サーバーからのダウンロードファイルあたり1K、決して真剣に。私たちは、職場での明確な責任を必要としています。
- 事故の後、それは回復不能な問題が生じ、ディスクに書き込まれたデータの一部を引き起こして、検出されませんでした。書き込みアプリケーション監視プログラムする必要があり、サービスが異常になると、SMSアラート責任者。
- コメントの通知によると、プラス：あなたが動作するには、rootユーザーを使用することはできません。あなたは、サーバー上のユーザー権限の異なるレベルを提供する必要があります。
下のこの事件の共有を通じて、ツールのリンクを本明細書中で使用されます：
1. https://code.google.com/p/ext3grep/
2. http://extundelete.sourceforge.net/
同様の原理でExt3grep機能も類似していなければなりません。あなたがインストールする方法について、インターネットを検索することができ、コンパイルし、より多くの依存関係をインストールします。[残念ながらHOWTO作者が壁を与えられた、私はあなたがLinuxファイルシステムのより良い理解を持つことになります読んだ後、PDFドキュメントをダウンロードしHOWTO FQます。]
このツールはバグがあり、エラーの後にダウン実行されません。
ext3grep：init_directories.cc：534：無効init_directories（）：アサーション`lost_plus_found_directory_iter ！= ALL_DIRECTORIES。最後は（）" に失敗しました。
パッチをダウンロード：障害回復で、その結果、著者は、パッチ、ダウンロードアドレスをリリースしました。
最後に、私は同僚少し友人は決して間違って、コードをノックして幸せこの記事イベントを、覚えることができることを願っています-