さんざんな年明けでした。
おまけに、このドコライフがある鯖が、ぶっ飛んでしまい、
その復旧に悩まされ続けた年明けでもあります。
最初は、いずれは寿命を迎える HDD のバックアップを
作っておいて、いざというときに備えておこうという
平和なものだったんです。
ところが、元の Centos6 起動ドライブが今は懐かしい
PATA だったので、これを丸ごとコピーしたSATA では、
起動しないだけではなく、Centos6 のインストールDVDにある
Rescue installed system で無理矢理起動させようにも
You don’t have any Linux parthisyon. Press
return to get a shell. The system will reboot
automatically when you exist from the shell.
となって前に進めません。
うーん。PATA から SATA にコピーするから起動できないんだ。
PATA から PATA にコピーしたら正常に起動するかも……と
思っちゃったんですね。（このときは直感でしかなかったの
ですが、最終的に、このカンは当たってたことがわかりました）
ところが、いくら物持ちがいい私でも、PATA をいくつも
持ってません。起動ドライブは 500GB でした。使えそうなのは、
不良セクタがあって 1.7GB くらい実容量が足りない 500GB の
PATA だけでした。
起動ドライブの sda2 は、論理ボリュームになってます。
今回、この論理ボリュームには、とことん、苦しめられるんですが、
このときは、起動ドライブの論理ボリュームを縮小させて
どうにか、1.7GB くらい容量が足りない PATA に丸ごと
コピーしようとしたのです。しかし、あえなく失敗。
そうこうしてるうちに肝心の起動ドライブが初期化さえ
できないほどに壊れてしまいました。
そこからが地獄の毎日。試行錯誤で思いつく限りの
方法を試していきました。でも試すたびに 500GB を
EaseUS Todo Backup でクローンするのですが、時間が
かかって仕方がありません。最終的にたどりついた方法は、
まず、SATA に Centos6 をインストールします。sda1 は
そのままに、元の起動ドライブのクローンの sda2 を
上書きします。まあ、木に竹を接いだ状態ながら、これが
起動できるんです。ただし、sda2 が Read-Only になるので
# mount -o remount,rw /dev/mapper/vg_ホスト名-lv_root
で再マウントさせると書き込みができるようにして
/etc/fstab の /boot の UUID を正しいものに書き換えます。
こうすると、木に竹SATA は見かけ上、正常に起動できる
ようになります。しかし、ネットワークの設定をして
# /etc/rc.d/init.d/network restart
再起動させると、
Shutting down loopback interface: [ OK ]
FATAL:Could not load /lib/modules/2.6.32-696.e16.x86_64/modules.dep: No such file or directory
Bringing up loopback interface: [ OK ]
Bringing up interface eth0: Dvice eth0 does not seem tobe present,delaying initialization.
[FAILED]
FATAL:Could not load /lib/modules/2.6.32-696.e16.x86_64/modules.dep: No such file or directory
実は、このときには、Centos6 の64ビット版がインストール
されているとばかり思っていたのです。だって、サーバー機の
CPU は 64 ビットですから。
その後、/lib/modules の中を見ることができるようになり、
# ls -l /mnt/lib/modules
合計 20
drwxr-xr-x. 7 root root 4096 9月 14 03:54 2017 2.6.32-696.10.2.el6.i686
drwxr-xr-x. 7 root root 4096 9月 29 03:32 2017 2.6.32-696.10.3.el6.i686
drwxr-xr-x. 7 root root 4096 10月 8 04:47 2017 2.6.32-696.13.2.el6.i686
drwxr-xr-x. 7 root root 4096 11月 17 03:48 2017 2.6.32-696.16.1.el6.i686
drwxr-xr-x. 7 root root 4096 1月 6 04:26 2018 2.6.32-696.18.7.el6.i686
だとわかり、32ビット版であることを確信するのですが、
この中に、2.6.32-696.el6.i686 というディレクトリは
ありません。そこで、sda1 の中身を書き換えたり、GRUB の
設定を変えたり、2.6.32-696.18.7.el6.i686 をリネームしたり
しましたが、いずれも失敗。
そして、今朝の未明に
新規インストールした 32ビット版 Centos6 に修復中の SATAを
USB接続してマウントして、新規インストール側から修復中
SATAへ /lib/modules /2.6.32-696.18.7.el6.i686 を
# cp -r /lib/modules/2.6.32-696.el6.i686 /mnt/lib/modules/2.6.32-696.el6.i686
コピーしました。そして、ついに仮復旧できたのです。
最後に、仮復旧できた SATA のクローンを作って起動させて
みました。てっきり、Read-Only になって、再マウントが
必要になると思いましたが、スルスルっと立ち上がって、
ネットワークもhttpd も問題なし。あれっ？っていう感じです。
自動的に fstab を書き換えてくれた？謎でしたが、あとで
クローン元とクローン先の fstab を比べてみたら、まったく
同じ（当然と言えば当然ですけど）
同じ SATAコネクタに繋げば、HDD を替えても同じ UUID に
なるということでしょうか？それなら、PATAからPATAへ
コピーできていたら、同じ IDE コネクタのスレｰブなら
スレーブに繋ぐわけですから、同じ UUID になって、
何もしなくても、そのまま起動できたってことですよね？
最後まで、UUID の概念がよくわかっていない私でした。
結局、２週間にもわたって鯖を止めてしまい、塗炭の苦しみの
中で復旧作業をした割には、レアなケースで今回の経験から
得た知識なりテクニックは、あまり他の方の役に立つ物は
なかったということでしょうかね。むろん、私自身も
理解できていないので役立たせることが難しいし、ほぼ、
8割がたは忘れてしまってるし……
クライマックスの論理ボリュームをマウントさせるところ
なんかも、google 先生の言うとおりに進めていたら、
その通りにならないので、あせりましたがマウントできて
いました？？？ひょっとして、自動マウント？
起動ディスクに PATA を使ってる人は少ないのでしょうけど
Centos6 を使ってる人も少なくなってきているのでしょう。
サーバーがこけてた期間中「メンテナンス中です。」と
告知させてたサーバーなんて、Centos５ ですからね。
ググっても、ほとんど情報がありません。
１４日ぶんですから愚痴は、まだまだありますが、WordPress の
バックアップについての研究に取りかかるためのモチベーションを
どうやって上げるかというのが次の課題でしょう。