絶え間ない努力の二日間を経験し、最終的には一度削除された本番サーバのデータの不正使用を再開しました。このレコードでの事故やソリューションのプロセスは、自分自身を警告とMoを示唆して他の人はこのミスを犯しました。私は友達が直面する問題は、問題を解決するためのインスピレーションの痕跡を見つけることができます願っています。
事故背景
本番サーバのOracle、姉妹エッジ研究側のインストールにインストールされている姉を配置し、インストールが再インストールをアンインストールする準備ができて感じることはありません。次のようにコマンドラインでは、Oracleのインストールディレクトリを削除し、実行する、インターネットからのアンインストールの検索、コマンドは次のとおりです。
ORACLE_BASE変数が割り当てられていない場合、コマンドはなり
ように、妹が使用されるが、rootアカウントああ。
このように、ディスク全体がそうでのTomcatのアプリケーション、MySQLデータベースとを含む、すべてのファイルを、削除します。。。。
MySQLデータベースは、それが完全に除去されているため、Linuxは？実行されているファイルを削除することができますか？実行し、そして最後に、ファイルが大きすぎると推定、そして時には正常に削除されていないTomcatのログファイルを残していません
妹が目を後悔見て、彼女が何をするために私が配置されたこの事で、任意のトレーニングなしで、責任だけ戻って一人することができ、賭け金は明確な彼女に言うと、それ美しいクマこの責任を作成する方法のほかにありませんでした？
部屋への呼び出しは、すべてのファイルが、このサーバが実行されているクリアされ、別のサーバー、SSHの回復基調ビューにディスクを掛けるが、お客様の生産システムは、ああ、できるだけ早くああとして復元された、6ヶ月間実行されています。そして、オフラインデータベースのバックアップのために送られ、バックアップファイルは、（問題のバックアップスクリプトのcrontabの実行されています）、その後、バックアップのほとんどは、実際に家の2013年12月にあることを確認おなじみのmysqldumpコメントの唯一の数行である、唯一の1キロバイトを見つけました表面上は無限雨ああ。それを考える指導者はケースは言った：生産システムがハングアップすると、すべてのバックアップは疑問を持って見つけ、DVDにも傷、テープドライブを持っている、以前の推定値はまた、バックアップCD-ROMを行い、（また、シニア産業悪いです）、私は本当に私の体を成就するために期待していなかった、どのように行います？
事態を知っ部門長の後、最悪の事態はプランBを行われている：AAと製品のリーダーシップは個人的に顧客がリーダーシップの通信に月曜日市に駆けつけ日曜日を主導し、BBおよびCCは、顧客の管理者に方法を見つけるためにあそこに行きます顧客を説得。。。
ストロー/ ext3grep
すぐに誤って削除されたデータの回復を情報を見つけるには、インターネットに、本当にext3grepはRM -rf、私たちも、ext3のディスクフォーマットによって削除されたファイルを回復することができ、そして多くのオンラインの成功事例がありますを見つけます。だから、再書かれて削除されたファイルの部門を作るために防ぐために、ディスクのアンマウントにかすかな望み、できるだけ早くを燃やし。ext3grepダウンロードし、インストールします（ビーイングがテーブルではない時間のために骨の折れるプロセスをコンパイルしてインストールします）。最初のスキャンファイル名のコマンドを実行します。
、すべて削除されたファイルとパスをプリントアウト喜び、プランBを実行せずに、ファイルがそれです。このソフトウェアは、ディレクトリでファイルを復元することができ、すべてのコマンドは、リカバリを実行することができます。
ディスクスペースの現在の不足、決して結果ファイルのみを復元することができ、いくつかのファイルを試し、それでも部分的に成功した部分的な障害
あなたは寒さを助けることができない、それはディスク上のファイルを削除するために書かれたのですか？回復のリトルチャンス、ああ、それはいくつかを復元することができ、いくつか、多分ちょうど、重要なデータファイルのMYDファイルを復元することができます数えます。ファイルファイルにリダイレクトすべてのファイル名の最初だから、
保存するために、すべてのMySQLデータベースのファイル名を除外し、mysqltbname.txt
スクリプトは、ファイルを回復します：
実行は、約20分、40以上のファイルの回復ではなく、十分なああを実行して、我々は300以上のああ程度があると言う方法を、ほぼ100テーブル、各テーブルのFRM、MYD、MYI 3つの文書を持っています！！既存のデータベースに添付されたファイルを戻ってくるだろうが、また、777のファイルのパーミッションに、再起動のMySQLは、バックデータの一部と考えることができますが、顧客は、出席データに署名することが重要であるデータの電話側の報告が（これらのデータは、顧客が言われていますああ戻ってきていない）従業員のパフォーマンスを行います。私たちは基本的に同じ原理は同じである必要がありますが、ディレクトリで復元すると言われて、うまくそれを試してみる？中東になって、別のツールを試してみましたextundelete、ext3grep文法とされています。
右合図に、回復は出てきません！！！！！！！！これらのファイルが破壊されました。レポートのリーダーシップでは、今プランBの実装。。。仕事から家に絶望（週末、戻って休憩を取る、方法を考えます）
インスピレーション/ビンログ
第二天早晨一早就醒了（心里有事啊），背上电脑，去公司（这个周末算是报销了，不挨批，通报，罚款，开除就不错了，还过什么周末啊）。依旧运行ext3grep，extundelete，也就那几招啊，把系统架到测试服务器上，看看数据能不能想办法补一补吧。在测试服务器上进行mysqldump，恢复文件，覆盖恢复回来的文件，给文件加权限，重启mysql。wait,wait，不是有binlog吗?我们服务都要求开启binlog，说不定能通过binlog里恢复数据呢?
于是从dump出来的文件名里找到binlog的文件，一共三个，mysql-binlog0001,mysql-bin.000009,mysql-bin.000010，恢复一下0001
居然失败了。。。。。。再看另两个文件，mysql-bin.000010大概几百MB，应该靠谱一点，执行还原命令，居然成功了！！！！！！！！！！！！！赶快scp到测试服务器。执行binlog还原。mysqlbinlog /usr/mysql-bin.000010 | mysql -uroot -p
输入密码，卡住了（好现象），经过漫长的等待，终于结束了。打开应用，哦，感谢cctv,mtv，数据回来了！！！！！！！！！！！！！！！
后记
经过此次事故，虽然数据很幸运能找回来了，但是过程却是惊心动迫。也为自己的错误所带来的后果，给同事和领导带来的连带责任而后怕。也希望谨记此次事故，以后不再犯同样的错误。事故反思如下：
本次安排MM进行服务器维护时没有提前对她进行说明厉害情况，自己也未重视，管理混乱，流程混乱。一个在线的生产系统，任何一个改动一定要先谋而后动。
自动备份出现问题，没有任何人检查。脱机备份人员每次从服务器上下载1k的文件却从未重视。需要明确大家在工作岗位上的责任。
事故发生后，没有及时发现，造成部分数据写入磁盘，造成不可恢复问题。需要编写应用监控程序，服务一旦有异常，短信告警相关责任人。
コメントの通知によると、プラス：あなたが動作するには、rootユーザーを使用することはできません。あなたは、サーバー上のユーザー権限の異なるレベルを提供する必要があります。
この事件を通じて、いくつかのこのプロジェクトでの事故と彼の同僚は同僚でもデータ復旧テストでは13:00時に役立つ、テストを支援するための情報を見つけるために、助けに来て率先して、任意の関係を持っていませんでした。ケース内の同じ時間のプロダクトマネージャーでパニックと開発者や特定の事業者を非難していなかった、顧客向け多大な圧力を期待していますが、私たちは停止し、解決策を考えることができるという。部門長にも積極的に、残業テストを働くリアルタイム追跡プロセスを実行するために私たちに同行する方法を見つけるのに役立ちます。私たちの努力を通じて、比較的成功裡の妥結次の月曜日の朝は、まとめ教訓を反映し、最終的に何かを学んだ、このような事件は大きな努力を回避しようとしなければなりません。
「Javaのコア知識.PDFを終えた」、「カバーJVM、ロック、など高い同時実行、反射、春の原理、マイクロサービス、飼育係、データベース、データ構造、」だけでなく、Java208舗装質問（インタビューブックを共有します）答えをへのアクセスを解放するためにグループ（Javaはピットロードを埋める）659 655 594に参加します！