途中からシングルユーザーモードで作業したため手順が書き留められなかったが、あれこれ試行錯誤してようやっと解決にこぎつけた。最終的には、ファイルの格納場所である「/share」を「/」とは別のパーティションにし、将来的にまた容量アップする際にもアンマウントできるようにしておいた。
まず、古いHDDと新しいHDDの組み合わせにして片肺状態で起動し、新しいHDDのパーティション設定をする。新たに作成するルートパーティションは、古いほうのそれから「/share」のぶんを引いた容量にする。今回は余裕を見て2GBを割り当てておいた。新しいほうのパーティションのうち、ブートパーティションである/dev/md0(とswapパーティション)以外は別のアレイを作成して暫定的にマウントする。あとは適宜「cp -ax」コマンドを使って必要なファイル群をコピーする。
ファイルコピーの済んだ新しいHDD(/dev/hdb)のブートパーティションにMBRをインストールして起動。残る一方のHDD(/dev/hda)のパーティションを設定するわけだが、古いアレイの情報が残っているため起動時にカーネルパニックを起こしてしまった。これを防ぐためには、どこかのタイミングで以下の処理をしておく必要がある(結局またレスキューCDから起動してやり直したわけだが)。
# mdadm --misc --zero-superblock /dev/hda
リカバリが済んだ時点で再起動し、RAIDが問題なく稼働していることを確認しサーバを業務に戻したのだが、途中でルートパーティションへの書き込みができなくなってしまった。どうやら/etc/mdadm.confに書かれた情報が古いままだったため、アレイが正常に構築されなかったのが原因のようだ。
# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 hdb2[0] hda2[1]
15004608 blocks [2/2] [UU]
md3 : active raid1 hdb3[1] hda3[0]
1052160 blocks [2/2] [UU]
md4 : active raid1 hdb4[0] hda4[1]
472222528 blocks [2/2] [UU]
md0 : active raid1 hdb1[1] hda1[0]
104320 blocks [2/2] [UU]
unused devices: <none>
# mdadm -Es
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=893eb1da:fdd9b37f:44522ab8:4dd4f874
devices=/dev/hdb1,/dev/hda1
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=c7dbadc1:074cdb02:c0dcdbed:bd5fc5a8
devices=/dev/hdb2,/dev/hda2
ARRAY /dev/md3 level=raid1 num-devices=2 UUID=2381ffdc:632fc8a6:ab24b372:8e6ac603
devices=/dev/hdb3,/dev/hda3
ARRAY /dev/md4 level=raid1 num-devices=2 UUID=a7a6c2ba:0ba19857:9c8cc859:2fae46bc
devices=/dev/hdb4,/dev/hda4
最後の「mdadm -Es」の出力内容を/etc/mdadm.confに反映させればオーケーであった。

Leave a comment