1/9から同11日まで、サーバが完全に沈黙してました。
状況としては、/varにマウントさせていたドライブ（外付けUSB−HDD）が、物理的な不具合を起こしたらしく、突然にログに大量のI/O errorの文字が吐き出され、そうこうしているうちにディスクが読み込み不可能となってしまった、という具合です。
/varディレクトリ自体は/以下にあるので（もちろん中身は空）、とりあえずシステムドライブにある/etc/fstabから、/varにこのドライブを自動マウントさせている記述をコメントアウトすれば起動するんじゃね？
と（ちょっと浅はかでした・・・）考え、ひとまずメンテナンスモードでログインすることに。
ところでメンテナンスモードは全てのディレクトリをreadonlyでマウントするため、このままの状態では/etc/fstabを編集することはできません。
なので最初に/を通常通りの書き込み可能な状態でマウントし直します。
# mount -o remount,rw /
これで読み書きOKなパーミッションでマウントされ直すので、続いて/etc/fstabを編集します。
# vi /etc/fstab
編集と言っても、行うのはこのドライブ（つまり/varにマウントさせているドライブ）のオートマウントを指定している行をコメントアウトするだけです。
そうしたら、再起動。
/varというディレクトリ（マウントポイント）自体はあるので、これで暫定的にマシンが起動する・・・と考えたのですが、これがどうも浅はかだったようです。
電源を入れると、こういう状態で止まってしまうようになってしまいました。
システムロガーを起動するには、/var/run/syslogd.pidなるファイルを読み込む必要があるのに、それがないから起動できないよ、と、そういうことのようです。
・・・敗北・・・orz
しかしうちのサーバはBLOG（WEB）サーバとしてだけ機能しているわけではないので、ここであきらめるわけにもいきません（どうしても復旧しないときにどうするかは念のため考えておきましたが）。
そして思いついたのが、現在のシステムドライブ（SSD）を外して別マシンにつなぎ、そこでもう一度/etc/fstabを編集、メンテナンスモードでのログインをできるようにして、/varにマウントさせていたドライブの中身を直接/varにコピーしちゃう、という方法。
というわけで、早速秘密兵器を購入！
購入したのはSATAの2.5インチHDD・SSDをUSBで外付けするためのケース。
玄人志向のGW2.5CR-U3です。バスパワー駆動で、ネジ不要とのこと。お値段は800円くらいでした。
玄人志向ですから、中身は必要最小限。とはいえ、ケースにSSDを入れて、USBにつなぐだけですから、これで十分でしょう。
ではATXケースからシステムドライブ（SSD）を取り外しましょう！
余談ですが、Linuxをインストールするために使った内蔵DVDドライブは、メディアを読み込めなくなっていました。なのでこの機会にこれも取り外します！
これがシステムドライブとして使っている、ADATAのSSD。SX-900、128GBです。
すっかり忘れてましたが、容量が128GBもあったんですね。これならこのドライブに/varのデータを入れても容量的には全く問題ないなぁ（別の理由でそれはしませんが）。
パイルダー・オン！（笑）
このSSDを恒久的に外付けとして使うわけではないので、とりあえずはこの状態で問題ありません。要はSSDがUSBにつなげればいいのですから。
これを、別Linuxマシンにつなぎ、マウントされたらこの中の/etc/fstabを編集するわけです。
ここで役に立ってくれたのが、かつてCentOS 6.xをインストールすることができず（CPUの機能が足りなかったようです）、継続使用することを断念していたものすごーく古いVAIO。
まさか再びこの電源を入れることになるとは。捨てずに取っておいてよかった・・・と本気で思いました。
なお、稼働しているのはCentOS 5.xです。
恐る恐るUSBポートにSSDをつなぎます。バスパワーなので繋げば自動的に電源投入となり、認識されるはずですが・・・。
ほどなくして・・・認識されました！
ウィンドウが二つ開いているのは、このSSDが/bootと/のパーティションに分けられているからです。もちろん今回使用するのは/パーティションであるdisk-1となっている方です。
コマンドラインでも問題無し。って、当たり前ですが。
これでシステムドライブの/etc/fstabを編集できます。
/etc/fstabの一部ですが、この/varにマウントさせる記述の頭にある#を外して、コメントアウトを解除するわけです。
・・・と、ここまで来て気がつきました。
今、当たり前ですがシステムドライブの/varにもアクセス可能です。
だとしたら、I/O errorのドライブ（ナイスなことにこれは外付けのUSB-HDD！）をつないで、読み取れる全てのデータを/varにコピーしてしまえば、/etc/fstabは現状のままにしてもいてもサーバが立ち上がるかどうか確認できるのではないか？
ちなみにこれが/varにマウントさせていたドライブ。I-OデータのHDH-U300という外付けHDDなのですが、何が優れているかというとファンレス仕様の上に、電源内蔵なのです。ACアダプタがいらないって、ものすごく取り回しがいいんですよね〜。
そこで早速このドライブも（こちらは電源をつないで）VAIOに接続。オートマウントはされませんでしたが（なぜだ？）、ドライブ自体は認識しているようです。
ならば手動でマウントさせるまでです。
# mount -t ext4 /dev/sdb1 /mnt
確認したところsdb1として認識していたので、ひとまず/mntにマウントさせて中身が見えるかどうかの確認です。
あ、見えた！
これは幸先いいかも。そうしたら急いで/mntの中身を全てシステムドライブ上の/varにコピーしてしまいます。
途中でエラーが出るかもしれません。ちょっとドキドキです。
# cp -ar /mnt/* /media/disk-1/var/
コピーを始めてから、-vオプションも付けておけばよかったと少し後悔したものの、これは後の祭り。
今はじっと成り行きを見守りましょう。
お、一つもエラーが返されることなく、全てのデータをコピーできたっぽい？
こうなるとついついこの外付けHDDを継続使用したくなってしまいますが、I/O errorが大量に返されたのは紛れもない事実。
ここは変な貧乏人根性は捨てて、このディスクの使用はきっぱりとあきらめることにします（電源内蔵の外付けケースとしては十分に利用できるはずですし）。
さて、これでシステムドライブ上に/varが再現されたはず。つまりこのシステムドライブだけでサーバマシンはきちんと稼働するはずですが、果たしてどうでしょう。
現時点では状況把握だけが目的ですから、ケーブルを接続しただけのプランプラン状態でマシンを起動させます。
SSDは軽量だからこうした取り回しも楽でいいですよね〜。
それでは電源投入！
ｷﾀ━━━(ﾟ∀ﾟ).━━━!!!
マシンが通常起動し、ログイン画面が現れました！
この段階までくれば、各種サーバは機能しているはず。試しにこのBLOGにアクセスしたところ、きちんと表示されました（LAN側からもインターネット側からも）。
消滅した記事もないようですし、完全に元通りっぽいです。
そうしたら最後に、手元にあった別の内蔵HDDをフォーマットし、/varへのマウント用のディスクにします。
ラベルをこれまでの/varマウントディスクと同じにしておけば、/etc/fstabの編集の必要はありません（コメントアウトを外すだけでOK）。
mkfsし、e2labelしたら適当なディレクトリに一時的にマウントし、/varの中身を先ほどと同じコマンドで全てこの内蔵HDDにコピーします。
そうしたら念のためもう一度サーバマシンを再起動させ、問題なく稼働することがわかったら、復旧作業の終了です。
しかし、今回使った内蔵HDDもそうですが、本来は信頼性が一番大切なはずのサーバに、使わなくなったパーツ（あまったパーツ）を用いて組み上げるというその心意気がいけないのかもしれませんね。
新しく/var用に使ったHDDなんて、今は亡きquantumのFireballシリーズですからねぇ〜・・・。
でも、所詮は自宅内に設置している趣味のサーバですから、そうそうこちらにコストをかけることもできず。
一応BLOGに関してはバックアップを取っていますが、データベースも含めた復旧方法の記事がBLOGにしか入っていないので、今回のようなことになったら復旧方法をまた一からインターネットで探さなければならないわけで。
もう少し運用の方法を検討しなくちゃいけないかな・・・との思いは、新たにしたのでした。
それにしても今年は年頭からいろいろなものが壊れるな〜。
このサーバのHDD、電気ポット、RVFのフロントタイヤ・・・。ま、それらにきちんと対処できているのだから、問題ないといえば問題ないわけですが・・・(~_~;;
