システム管理者は、バックアップしない人と、 すでにバックアップしている人に分けられます=）
ext3 / ufsからファイルを復元する方法について複数の記事が書かれているので、ここでは繰り返しません。運用サーバーで構成を復元する最も広く知られている方法については書きません。
これはどのように起こりましたか？
夕方、現在ウェブスタジオで働いている古い友人からの電話。 反対側には、完全なパニックと不確実性があります。
-！「いいえ。％：AAAa！すべてが落ちたが、何も機能しない。私はカペッツだ、助けてくれ。
人を適切な状態にし、何が起こったのかを見つけてから15分後に、次のことが明らかになりました。
- 彼らのスタジオはサイトを作成するだけでなく、サイトをホストしています。
- nginx構成は、場所を引き出してMySQLサービスデータベースから書き換えるスクリプトによって生成されます。
- ベースは、RAID-1とマスター/スレーブレプリケーションを備えた優れたサーバー上にあります
- 「両方のサーバーの両方のネジが死ぬ可能性がゼロ」であるため、バックアップは行われません（c）このスタジオのシステム管理者
バックアップについて
真実は真実です。 実際、4本のネジを同時に死ぬことはできません（可能性がありますが、統計的には© "Charlie" Eppes、Numb3rs ）、何らかの理由で、人々はRAID-1でrm -rf / *を実行しても両方のネジで古いまた、あるサーバーから別のサーバーにDROP TABLEが複製されていることも忘れています。 また、いつの日かオフィスが火災のために燃え尽きるか/洪水によるdr死/地震による崩壊/経済犯罪省との立ち去りを疑う人はほとんどいません。 一般に、オフサイトバックアップを行う人はほとんどいません...しかし、無駄に少なくとも1か月に1回は、すべてをUSBフラッシュドライブにパスワードで保護された.rarにマージし、手間をかけずに手で持ち帰ることができます。
ZFSスナップショットもRAIDもレプリケーションも、バックアップの代わりにはなりません。 これらはすべてデータを失う可能性を減らしますが、そうであることは非常に良いことですが、常にオフサイトバックアップがあるべきです！
要点をつかむ
マーフィーの法則では、起こりうることは単に起こるに違いありません。 したがって、この不運な夜に、UPDATE SQLクエリのエラーにより、nginx'a configの生成元のデータを含むサービステーブルがいっぱいになり、 '' nginx.confスクリプトのエラーにより、空のファイルで上書きされました。 幸いなことに、nginxは賢いものであり、設定をリロードする前に、それが正しいかどうかを確認するため、新しい設定nginxの使用を拒否しました。
上書きされた構成を復元する方法は？
私の古い友人は、nginxでフロントエンドへのアクセスを許可してくれました。
ここではすべてが普通です：FreeBSD上のマシン、2つのディスク上のgmirror、nginx、それ以上。
最初に停止したのはgmirrorであったため、2番目のネジのファイルがすべての変更によって上書きされることはありませんでした。 その後、彼はディスクから殺されたファイルを回復する方法について考え始めましたが、サーバーの稼働時間を見て、友人が言ったことを思い出しました、彼らは言う、構成はめったに変更されないので、別の方法を試してみることにしました。
スワップの数を調べました。
# swapinfo
Device 1K-blocks Used Avail Capacity
/dev/ad4s1b 2063152 94612 1968540 5%
彼が現在5％で忙しいという事実は、情報の5％だけが存在することを意味するものではありません。
現在の状態を保存する
# cat /dev/ad4s1b > /usr/SWAP
そして、構成からの文字列がどのスレッドをつかみ始めるかを知る。 ほとんどの人がfryahuとnginxの両方を「Sysoevに従って」調整するので、おそらくconfigに「reset_timedout_connection on」という行があります。まあ、運を確認して修正してみましょう。
# cat /usr/SWAP | grep -a -A10 reset_timedout_connection
Lj Lj Lj Lj Lj Lj$ Lj0 Lj8 Lj< LjX Lj\ Ljd Ljp Lj Lj Lj Lj Lj Lj Lj Lj Lj Lj Lj8 LjP Ljp Lj Lj Lj Lj Lj LjX Lj
Lj Lj m [Ȉh LjxȈҰLj@ . ` ` 0u 0u2 d d Lj Ȉ<4 @TȈ Ȉ
--
reset_timedout_connection on;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
send_lowat 12000;
keepalive_timeout 65;
gzip on;
gzip_min_length 2048;
gzip_types text/css text/js text/xml;
^C
そして、ここで、設定の一部であるvoilaは、値-Aおよび-Bで遊ぶだけで、設定全体をアンフックし、最新の/無敵のオプションを選択します（スワップにいくつかあるかもしれません）
# cat /usr/SWAP | grep -a -A400 -B12 "reset_timedout_connection on;"
私たちの手ですべての設定。 売上は壊れておらず、関連性はないようです。 これで、それを解析して、MySQLテーブルを復元できます。
この方法は万能薬や特効薬ではありません。私の場合はルールではなく例外として機能しましたが、一部の人にとっては、この方法はスレッド後に重要なデータを復元するのに役立ちます。
swap'eがなく、ファイルをネジから復元できない場合
また、nginxプロセスがサーバー上でまだ実行されている場合、情報を回復するための、あまり好ましくない2番目のオプションがあります。
まず、nginxマスターを探します
# ps -auxww | grep nginx
root 1197 0,0 0,1 13216 2488 ?? Is 18 0:00,02 nginx: master process /usr/local/sbin/nginx
www 29484 0,0 2,3 57248 47576 ?? I 7:58 0:00,06 nginx: worker process (nginx)
次に、コアダンプを与えます
# gcore 1197
そして、必要に応じてそれを選択します
# cat core.1197 | strings | grep -B10 -A10 reset_timedout_connection
そうであっても
# cat core.1197 | grep -a -B10 -A10 reset_timedout_connection
...そして、構成を1つずつ組み立てるのがどれほど難しいかを恐れています
おわりに
人々は、自分自身を邪悪なピノキオにしないで、頻繁に十分に保護された自動データバックアップを行います。 そして、最も深いお尻からでも少なくとも2つの出口があることを覚えておいてください％）
あとがきの代わりに
MySQLデータベースは最終的に復元されました。 管理者自身は、それを知らずに、データベースの寿命の最初から--bin-logをオンにしました（ちなみに、binlogデータベースの復元を開始するまでに既に89％/ varを占めており、数か月後にmysqlは実行を停止しました）。 誰もそれらを削除していないという事実のために、 Point-in-Time Recoveryを行うことが可能でした
PS。 リクエストに応じて、nginxが現在の設定または現在の設定との差分を発行し、ディスク上のファイルにあるものが=）