Clever Geek Handbook

OSの一部を削除した後のリモートサーバーの復元

最近、Habréに関する興味深い記事がいくつかあります（たとえば、 1回 、 2回、同僚の多くの企業ブログなど）。読んだ後、アイデアが生まれました。



今日、オペレーティングシステムの一部を削除した後、Linuxを使用して仮想マシンへのアクセスを復元することについて。



コンテンツが視聴者にとって興味深いものである場合は、同様の記事をいくつか書いてみます。









問題の声明



2012年の初めには、異なるデータセンター間で複数のLinux仮想マシンのv2v移行を行う必要がありました。 理由はわかりませんが、すべてのパーティションのrsyncを使用した方法を選択しました（もちろん、カーネル設定/モジュール/ initrd / grubなどの標準的な手順を使用したwitchcraft）。



サーバーは「大量」だったため、データは重要であり、複製は不可能でした。チャネルは狭く、厳しいダウンタイム要件、期限-昨日など。 など、その後、同期のいくつかの段階で詳細な作業計画を描いた後、変更の事前同期を行いました。 重要なポイントは、仮想マシンがプライベートクラウドにあったため、仮想マシンのコンソール（移行元のターゲット）へのアクセスの欠如でした。 厳しい条件は顧客によって決定されました（すべてをすばやく、安く、効率的に行うという古典的な願望）、したがって、私たちは可能な限り自分自身を確保しました：リスクについて警告され、私たちは自分自身でバックアップを作成し、お尻のバックアップを要求しました夜の「Windows」は同意しました-トラブルの前兆はありません。



仕事の始まり



さらに、マーフィーの法則によれば、何かが起こる可能性がある場合、それは起こります。



ヒューマンファクターが介入しました。同期前の段階で、管理者はrsync引数を混同し、送信元アドレスと宛先アドレスを誤って入れ替えました。 同期がマウントポイント/ usrからのものであり、管理者がなんとかコマンドの実行に気づき、すぐに中断したという事実によって、データ損失から救われました。 その結果、ディレクトリ/ usr / {bin、lib *、sbin}がヒットしました-それらからのファイルのいくつかは削除されました。 主な問題は、多くのライブラリがないために、新しいセッションを開いたり、rsyncを実行したり、パッケージマネージャーを使用してすべてを復元したりすることができないことでした。一般に、起動されたものと特別な依存関係のない基本ユーティリティのみです。 夕方はだらしないようになりました...



その後、ブレーンストーミングセッション、仮説テスト、状況から抜け出す方法が組織されました。 みんな楽しんでいた。 並行して、「ゼロから」作業を実行し、残されたものを起動するオプションが作成されましたが、これは変更されたデータの期限と損失を意味します。



回復の説明



すぐに予約を行うと、このアルゴリズムは万能薬ではなく、必ずしも最適なソリューションではありませんが、大きなプラスがあります-迅速かつ正常に機能しました。



アイデアは、ドナーを見つけ、不足しているデータをコピーしてrsyncを実行し、rsyncを実行し、すべてのライブラリ/コマンドを復元し、バックアップからパッケージ整合性制御システム/ diffを通過し、必要なデータを削除することです。



「壊れた」サーバーのスキャンがすぐに機能するようになり、同様のOSを備えた動作中のサーバーが見つかったため、ライブラリーとプログラムをそこからコピーするドナーとして使用することにしました。



トランスポートの問題は未解決でした。「beat打された」サーバーでは何も機能しません。 そのtelnetです。 それから、GETリクエストを簡単に送信できることを思い出しました。 可能であれば、それが必要です！ * nixのすべてはファイルの形式で保存されているため、必要なデータを含むアーカイブをUnicodeテキストファイルに変換し、プレーンテキストとして転送できます（telnetを介して比較的一貫性のあるデータを転送する有効な方法はすぐには見つかりませんでした）。



問題のあるサーバーでは、逆のタスクはデータを受信し、アーカイブに変換し、解凍し、rsyncを動作状態にすると、すべてが時計仕掛けのようになりました。



本番サーバーでいくつかのアクションが実行されました（条件付き）：



  1. 必要なものをアーカイブに収集します。 



    tar zcf /tmp/usr.tgz /usr...


  2. バイナリ形式からテキスト形式に変換します。 



     cat /tmp/usr.tgz | busybox uuencode -m - > usr.txt


  3. 壊れたサーバーからのアクセスがあるWebサーバーに移動します。 



     mv usr.txt /var/www/html


破損したサーバー（条件付き）：



  1. ファイルをダウンロードしようとしています： 



     telnet workserver 80 > usr.txt GET /usr.txt


  2. head-30 usr.txtサービスヘッダーが占める行数を調べます（sedを使用してbase64をすぐに切断できますが、セキュリティ上の理由から、手で調べることにしました）。 



      Trying workserver... Connected to workserver. Escape character is '^]'. HTTP/1.1 200 OK Date: Fri, 17 Jan 2013 13:13:50 GMT Server: Apache Last-Modified: Fri, 17 Jan 2013 13:11:32 GMT Accept-Ranges: bytes Content-Length: 262635116 Connection: close Content-Type: text/plain; charset=utf-8 begin-base64 644 - bmV0LnNoLm1lAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA


  3. コマンドで最初のhttp行を削除します（begin-base64行までの1行目から12行目までを削除します）。 



     sed -e '1,12d' usr.txt


  4. テキスト形式からバイナリに戻す： 



     busybox uudecode -o /root/usr.tgz usr.txt


  5. /root/usr.tgzを解凍し、削除されたファイルを手動で転送します。

  6. rsyncが機能しているかどうかを確認し、機能していない場合は、不足しているものを探します。機能している場合は、rsyncを実行し、サービスフォルダーを作業コピーと同期します。

  7. 何が変更されたか（条件付き）を探しています： 



     rpm -Va | tr -s ' ' | sed -e 's/\ d\ /\ /g' | sed -e 's/\ c\ /\ /g' | cut -f2 -d' ' > va2.xt rpm -qf $(cat va2.xt) | sort -n | uniq > reinstall.pkg yum -y reinstall $(cat reinstall.pkg)


  8. 影響を受けるパッケージによっては、再起動が必要な場合があります（バックアップの変更を削除し、別のサーバーにロールバックするオプションを設定し、できればカーネルを再インストールした後、すべてが読み込まれることを3回確認します）。


まとめ



割り当てられた時間を満たすことができました。 ビジネスは問題を感じませんでした。 それにもかかわらず、状況の徹底的な分析を実施し、将来、そのようなエラーは繰り返されなくなりました。

技術面からは、次の点に留意されました。





More articles:


All Articles