　しかし、バラせばバラすほど、どこにも作りが特殊な部分は見つからない。フツーのATAのHDDが、マスター設定で、プライマリ側につながっている。マザー上にも特にヘンな接続はない。COM2が前面のLCDパネルにつながっているのと、PCI上のギガ蟹のLEDが前面パネルに引き出されているくらい……となると、BIOSの中身が特殊？　それは、あまり考えたくはないが……。

　バラした状態でいつまでも眺めていてもどーしよーもないので、元通りに組み立てる。もう一度レスキューモードで上げて、grub-install……うまくいかない。どーしても、RAID1からシステムを起動したいんだけどなぁ……どーにもうまくいかない。

　悩み続けていても仕方ない。フツーにインストールしてみよう。改めてフツーにインストールする。パッケージは最小。あれ？　動く？　起動するじゃん!?　とりあえず、ちょっと安心。これでインストールできなかった日には、いきなりNASがレンガに変身するところだ。

　ソフトRAIDを妙な設定にしたのが原因なんだろうか？　となると、この状態から、システムをミラーリング状態に持ち込まなければならないことになるが……と、ココらあたりで、なんでHDDを1台しか搭載していないサーバで、そんなにオイラがミラーリング構成を組みたがっているのか説明しておこう。

　別に1台のHDDでミラーリングするのが目的ではない。ミラーリング機能を利用したバックアップ環境を実現したいというのが目的である。一般に、バックアップに求められる条件としてはいくつかあるが……

サーバの停止を伴うか、バックアップの所要時間はどれくらいか
バックアップファイルの形態、利用が容易かくて
バックアップに必要な容量、履歴管理が可能か

　 ……くらいかな。で、オイラがもっとも重要視するのが、最初の条件。バックアップに時間がかかってもいいから、サーバを停止することなく、スナップショットが取りたい、という要求である。

　で、2番目の条件も重量。Linux標準のdumpでバックアップすると、1個のデカいファイルになってしまう。テープにバックアップするのが前提ならそれで仕方ないが、ちょっと昔のファイルにアクセスしたいだけなのに、バックアップの目録を見ながら個々にファイルを書き戻してから……なんぞウザくてやってられないッ!!

　この点、平時はRAID1の片肺を「崩した状態」にしておき、バックアップを取りたいときにUSBのHDDを接続して「RAID1の復旧」を行い、RAID1の再構築が完了したところで「片側を切り離す」というバックアップ手法を取れば、システムに負荷をかけることなく、無停止でバックアップを行うことが可能なのである。たぶん、RAID1の切り離しはATOMICに行われるであろうからバックアップはスナップショットにほかならないし、なんといっても、切り離したディスクはそのままmount可能な形式なのである。この扱いやすさは最強だ。おまけにバックアップの進捗を/proc/mdstatでビジュアルに監視できる楽しさもある。

　世間一般では、スナップショットならLVMを使うのが素直であるが、いまだLVMの安定性には問題がある。また、接続しっぱなしでRAID1運用するという手もあるが、接続しっぱなしだと落雷で同時に破損する可能性は避けられない。やはり平常時は切り離しておきたい。切り離しておけば電力も食わないしね。

　ちなみにこのバックアップ法は最後の条件には不適である。んが、どうせオイラは数週間に一度くらいしかバックアップしないだろうし、履歴管理したければ改めてDVD-Rに書き出せばいいのだ。そのために、パーティションサイズはあらかじめ4GBに設定してある。

　と、RAIDを組みたい理由はそんな理由なのだが、どうにも既存のインストールを、うまくRAID状態に持っていくことができない……つーか、そもそも最初にソフトRAIDでのインストールした際に起動しなかった理由がわからない……ダメモトでもう一度やってみる？　えぃ……

　できるじゃん!?

　 ……な、なんだ？　最初と同じ手順で作業したはずなのに(そもそもRHEL4のインストールの際、そんなに多くの選択肢はない)見事にRAID1から起動できてしまった。そういえば、昨日はメモリチェックが始まらなくて強制リセットかけたりしてなんだか安定しなかったが、今日は非常に安定している……慣らし運転じゃないが、どこかしらのエージングが進んで動作が安定してきたのだろうか？　まぁ、特に電源とかはロジカルなパーツではないから、あながちありえない話でもないだろうが。

　つーわけで、起動しちゃえばこっちのもの。以下のようなコマンドで「同ドライブ上のRAID1」を縮退、切り離す。

# mdadm --manage /dev/md0 --fail /dev/hda2
# mdadm --manage /dev/md0 --remove /dev/hda2
# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hda1[0]
      4192832 blocks [2/1] [U_]

　バックアップのテストを始める。USBのHDDを接続して、ほぼ同容量のパーティションを確保し、以下のコマンドを実行。

# mdadm --manage /dev/md0 --add /dev/sda1

　この直後からリビルドが開始され、しばらくすると……

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[1] hda1[0]
      4192832 blocks [2/2] [UU]

　 RAIDの再構成は完了。この時点でバックアップ完了である。再度、切り離す。

# mdadm --manage /dev/md0 --fail /dev/sda1
# mdadm --manage /dev/md0 --remove /dev/sda1
# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hda1[0]
      4192832 blocks [2/1] [U_]

　切り離した領域は、mount /dev/sda1 /mntで、極めてフツーに扱うことができる。当然、書き込みも可能だ。ちなみに、新たにRAIDバックアップ可能な領域を作るには以下のコマンドでOK。

# mdadm --create /dev/md1 --level 1 --force --raid-devices=1 /dev/hda2

　また、こんな実験もしてみた。RAID1を3連ミラーにするのだ。

# mdadm --grow /dev/md0 --raid-disks=3
Personalities : [raid1]
md0 : active raid1 sda1[1] hda1[0]
      4192832 blocks [3/2] [UU_]
# mdadm --manage /dev/md0 --add /dev/sda2
Personalities : [raid1]
md0 : active raid1 sda2[2] sda1[1] hda1[0]
      4192832 blocks [3/3] [UUU]

　 growオプションはカーネルが2.6でないと動かないらしいが、当然RHEL4ならば問題なく動く。なお、grow(増やす)といいつつも、1を与えれば、1連ミラー(？)に減らすこともできる。

　つーわけで、ずっと前から構想を練っていた「ミラーリングバックアップメソッド」を、やっとこさ実現することができた。今度こそ、次期サーバの設定にとりかかろう。ではまた。

[ツッコミを入れる]