ほとんどログインしないで使っているUbuntuなサーバだが、時々はアップデートのためにログインして確認はしている。とはいえ、うっかりすると怠りがちになるものだ。
　土曜日*1、スラドJで、Ubuntu9.04がリリースされたという記事を見た。なんでも、8.10からなら自動アップグレードできるとか。セキュリティアップデートを見込んで、アップグレードをやってみた。えてして、こういう時にこそトラブルの神が舞い降りるものなのである。
　アップグレード自体はさくっと終わる。Windowsのそれに較べても拍子抜けするくらい簡単だ。まあ、カリカリにチューニングした環境でもないし。アップグレードで不要になったライブラリ類を消してくれるのもいい。ルックスが少し変わる位で、ほとんどの設定は引き継いでくれる。だが、やはりトラブルの種はあるものだ。
　全ての処理を終え、改めて再起動する。すると、Xログイン画面に移行する前、ドライバ類のローディング直後くらいに、なにやらエラーを吐いてメンテナンスログインを要求されるのだ。メッセージを読むと、なにかのドライブを読もうとして、しかしファイルシステムが予期しているEXT3ではないので止まっているようだ。メンテナンスモードに入り、全てのドライブを読めるか試してみると、どうもソフトウェアRAIDでファイルサーバ用にマウントしているsdb,sdcが見えてない。写真データ、そしてLANTANKトラブル後にはインターネットで集めた各種データの溜まり場だったドライブだ。後者はともかくとして、前者は二度と手に入らない。Picasaに上げてるのなんて、全体の数パーセントにも満たないくらいだ。400GBを越えていたはず。
　嫌な汗が出る(汗)。とりあえずこのエラーを無視して、メンテナンスモードを抜けて通常のログインをしてみた。
　状況を確認する。mdadmは稼動しているようだ。sdb、sdcのパーティションも正常*2だった。ならば、と、mdadmでbuildを試してみると、誰かがsdbを捕まえているとかでbuildできない。createでも同じ。force-createを試す度胸は無かった。そこで今一度メンテナンスモードに落ち、ここでbuild*3をしてみると、正常に処理が完了し、改めて再起動するとちゃんとマウントされて*4いた。ああ、ドキドキした(汗)。
　その他、なぜかsquidが起動されてないので調べてみると、sda6に切ってあるsquid用パーティションが、fstabでは何故かsdc6に変わっていたりした。誰が勝手に書き換えたんだろう。
　とまあ、マイナーなトラブルはあったが、概ね無事にアップデートできました。
　しかし、今回のことで改めて思ったのは、RAIDにしても可用性を高めるだけで、バックアップにはならないということだ。それは分かっているのだが、さすがにこのサイズのデータのバックアップを用意するのは並大抵ではない。サーバ多重化が現実的な解かな。って、また機械を増やすんかい。

• 注1正確には金曜日の深夜
• 注2Software RAIDフォーマット
• 注3いや、createだったかも
• 注4fstabの設定は引き継いでいたので