ホームサーバー 〜Fedora29 アップデート失敗⁈〜

つい先日、アップグレード失敗対応が終わったばかりのホームサーバーにOSのアップデートがありました。ちょっと不安な気持ちになりながらも、今ならシステムもデータベースもWordPressもバックアップがそのまま使える...ということで、思い切ってOSのアップデートを実施しましたが...

嫌な予感的中

OSのセキュリティ・アップデートやブラウザなどのアップデートなど、全部をまとめてアップデート...再起動..............................また、起動できない...エラーメッセージが表示されました。なんじゃこりゃあ。(* ´艸｀)ｸｽｸｽ　笑ってる場合じゃないんだけど。

よく見てみると、journalctlってタイプしてsystem logを見ろといってるみたいなので、コマンドを入力するとシステムログが表示されます。

エラーメッセージ
Generating “/run/initramfs/rdsosreport.txt”

Entering emergency mode. Exit the shell to continue.
Type “journalctl” to view system logs.
You might want to save “/run/initramfs/rdsosreport.txt” to a USB stick or /boot after mounting them and attach it to a bug report.

システムログの確認

表示されるシステムログは、問題のある箇所が赤字で表示されますので、注意しながら見ていると直ぐに問題箇所を見つけることができます。ファイルシステムが壊れていて正常に認識できていないみたいです。

問題箇所
fsck failed .........
　～中略～
Failed to start file System Check on ファイルシステム

ファイルシステムの修復

ファイルシステムのチェックと修復を行うfsckというコマンドを使って、ファイルシステムの修復を試みます。オプションには、障害発生時に修正する場合に利用が推奨されている。-fオプション（ファイルシステムがクリーンな場合でも全てのチェックを行う。）を指定します。コマンド実施後、何度か確認を求められるので、何度もyを入力するのが面倒な方は、修正箇所が見つかった場合に実行者に確認せずに修正を行う。-yオプションも併せて指定すると良いと思います。ファイルシステムの部分には修復するファイルシステム...つまり、システムログの確認で問題箇所として特定したファイルシステムを指定システムを指定してコマンドを実行。修復が完了したら、再起動して作業が完了です。

ファイルシステムの修復
fsck -fy ファイルシステム

今回は、この方法でリカバリーできましたが、必ずリカバリーできるものではないので、自分で運用、保守をしている方は、定期的にバックアップを取ったり、システムに変更を加えた時にバックアップを取ったりして、いざという時に備えるようにして下さいね。

ホームサーバー 〜WordPressブログ バックアップ／リストア〜

以前、レンタルサーバーのCPU使用制限超過でリダイレクトされてしまった時には、WebサーバーもWordPressブログも起動出来ていたので、phpAdminでWordPressデータベース全てのバックアップを取りましたが、今回はWebサーバーもWordPressブログもPHPも動いていない状況です。そして、ホームサーバーなのでFTPは使わずに直接外付けディスクを接続してWordPressブログのWebページをバックアップできます。

データベースバックアップ／リストア

最初にデータベースのバックアップを取ります。ホームサーバーなので外付けディスクを直接接続して、転送容量を気にせずにバックアップを取ることができるので、念のため全データベースのバックアップを取ることにします。何度も調べなくて良いように、特定のデータベースをバックアップ／リストアするコマンドも残しておくことにします。

MySQLデータベースバックアップ
特定のデータベースのみバックアップする場合
mysqldump --single-transaction -u ユーザー名 -p DB名 > 出力ファイル名

全データベースをバックアップする場合
mysqldump --single-transaction -u ユーザー名 -p -x --all-databases > 出力ファイル名

MySQLデータベースリストア
特定のデータベースのみリストアする場合
mysqldump -u ユーザー名 -p DB名 < バックアップファイル名

全データベースをリストアする場合
mysqldump -u ユーザー名 -p < バックアップファイル名

 WordPressブログバックアップ／リストア

次にWordPressブログのバックアップです。こちらも、転送容量を気にせずにバックアップを取ることができるので、念のため全データのバックアップを取ることにします。あちこち見ないで良いように、最低限のデータをバックアップ／リストアする方法も残しておくことにします。リストアは、各ディレクトリにバックアップしたデータを上書きすれば良いのですが。

WordPressブログバックアップ
最低限のデータのみバックアップする場合
1.~/wp-config.php
2.~/wp-content/plugin/　  ⇒　プラグイン格納
3.~/wp-content/themes/　⇒　テーマ格納
4.~/wp-content/uploads/　⇒　アップロードデータ格納

全データをバックアップする場合
WordPressのインストールディレクトリ配下の全データ

データベースのリストアでなく、WordPressのエクスポート機能で出力したXMLファイルをインポート機能でリストアする場合は、以前、使用していたテーマ、プラグインを有効にし、以前と同じパーマリンク設定をしてから、XMLファイルをインポート機能でリストアして下さい。正しく記事が復元されないのでくれぐれも注意して下さい。

使用していたテーマ、プラグイン、以前と同じパーマリンク設定が思い出せなくても手間は掛かりますが、最後の手段が有ります。MySQLのバックアップデータやWordPressのエクスポート機能で出力したXMLファイルは、テキストエディターで開くと記事の内容を読み取ることが出来るので、コピー＆ペーストなどで復元することが可能です。

ただし、データベースのバックアップには、記事の履歴（修正の度に保存される各リビジョンのデータ）も含まれていますので、最新の情報を見るようする必要があります。

ホームサーバー 〜WordPressブログ トラブル復旧〜

ホームサーバーで、運用しているWordPressブログサイト、MataKitena BlogがOSのアップグレード失敗で起動できなくなったトラブル対応の続きです。今回は、Webサーバーのapacheが起動出来て、無事にWordPressブログが起動出来たので、原因と対応方法を記事に残しておきます。データベースのバックアップとリストアについては次回記事にしますね。

WordPressブログが起動できない原因は

WordPressブログがどうして起動できないのか調べて分かったことは、データベースであるMySQLは起動出来ているということ。そして、Webサーバーのapacheを起動させてみたら...何やらPHPのライブラリに存在しないものがあると、エラーメッセージを出力して異常終了しているようです。これで、原因がはっきりしました。libnsl.so.1が存在しないので、Webサーバーが異常終了してしまいWordPressブログが起動出来ないのです。後は、インターネットで情報を探して対応すれば起動できそうです。

出力されたエラーメッセージの一部
...Cannot load modules/libphp7.so into server: libnsl.so.1: cannot open shared object file: No such file or directory...

そして、対応方法を探しに...

こういうことを調べている時に多いのですが、エラーメッセージをコピー&ペーストして検索すると英語のページがたくさん見つかるんです。英語が苦手な方は挫折しそうになっても、もうちょっと頑張って下さい。ここで、Google翻訳の出番です。検索結果のページを丸ごとか、部分的に翻訳すればほとんど日本語になった文書に翻訳されます。下記が、検索結果の中で1番解り易そうなページの要約です。なるほど...

発見した情報
Fedora 28以降で、msendユーティリティを使用しようすると、libnsl.so.1がnot foundと表示されるとのこと。

その原因は
Ferdoa 28以降、libnslパッケージはデフォルトでは含まれなくなり、libnsl2のみになったとのこと。

その対応方法は
後方互換性があるはずなのでlibnsl2ライブラリをlibnslにソフトリンクをしてみるか、libnslをインストールすればいいとのこと。 

ということは...利用しているOSが32bit、64bitのどちらかによって下記のコマンドでインストールできます。MataKitena Blogは、32bitなので、”dnf install libnsl”を実行してコマンドからWebサーバーのapatchを起動...起動完了です。念のため、システム起動時に自動起動されるかも確認しましたが、問題なく起動できました。

libnslのインストール方法
32bit OSの場合：dnf install libnsl
64bit OSの場合：dnf install libnsl.i686

ホームサーバー 〜WordPressブログ システムバックアップ〜

ホームサーバーで、運用していたWordPressブログサイト、MataKitena BlogがOSのアップグレード失敗で起動できなくなったトラブル対応の続きです。システムバックアップとリストアについて記事を残しておきます。

システムバックアップとは

システムバックアップとは、いざという時のためにパーティションやハードドライブ全体のイメージをバックアップすることをいいます。本来は、今回のようにサーバー自体が起動できなくなる可能性があるOSのアップグレードなどの作業を実施する場合には、事前にシステムバックアップをしておけば、リストアすることで元に戻すことが出来るので安心できます。とはいえ、ハードドライブ自体が壊れてしまった場合、復元することは不可能なので壊れる前にバックアップすること。更に、同一システム内のハードドライブでは、不注意や予期しない事態で壊れることもありますので、外付けのハードドライブやクラウドにバックアップデータを保存するようにしましょう。

システムバックアップの方法は

ddコマンドを利用します。ddコマンドはdataset definitionの略で、ディスクに限らずデータをLowレベルで読み書きできるので、データの中身を無視して操作でき、OSが読み取れないファイルシステムでフォーマットされている場合にもバイナリーレベルで読み書きすることができます。 バックアップしたいドライブ以外から起動する必要があるので、Bootable USBやBootable DVDなどを作成しておきましょう。ddコマンドは、ifで指定した入力ファイルを指定されたブロックサイズで、必要に応じて変換をしながらofで指定した出力ファイルにコピーすることができます。OSのディストリビューションやバージョンにより異なる場合もありますので、利用するシステムのmanコマンドで調べたり、確認して下さい。

ddコマンド書式
dd [--help] [--version] [if=file] [of=file] [ibs=bytes] [obs=bytes] [bs=bytes] [cbs=bytes] [skip=blocks] [seek=blocks] [count=blocks] [conv={ascii, ebcdic, ibm, block, unblock, lcase, ucase, swab, noerror, notrunc, sync}]

今回はどうしたの

今回、ディスクユーティリティで起動ディスクを調べてみると.../dev/sda1と/dev/sda2の2パーティションが存在しました。準備しておいたBootable CDから起動して、それに合わせ、より大きな容量の外付けディスクに、より大きなサイズのパーティションを作成してシステムバックアップを実行しました。リストアは、if=で指定した入力ファイルとof=で指定した出力ファイルを入れ替えるだけです。まだ、WordPressブログが起動できていないですが、何か起こったとしても現在の状況までは戻すことが出来ます。

参考：今回実行したコマンド
dd if=/dev/sda1 of=/dev/sdb1 bs=64k conv=noerror,sync status=progress
dd if=/dev/sda2 of=/dev/sdb2 bs=64k conv=noerror,sync status=progress

あとは、データベースを含め、WordPressブログをバックアップして、本格的に復旧作業に備えます。