復旧の肝

社内サーバー（CentOS4.6）のHDDが壊れかけていた（IOエラーが発生して強制的に読み取り専用モードでマウントされる）ため、昨日は1日復旧作業に費やしました。

その復旧作業の中で詰まった点などを書いておきます。
たまたま自分の環境でうまくいっただけかもしれませんので、
ここに書いてあることを真似するときは自己責任でお願いします。

１．新マシンに旧マシンのHDDを繋いでも普通に起動する

これは壊れかけてるHDDにトドメを刺すことになるかもしれないし、
こんなことしなくでもデータの吸い出しはできるので、全くおすすめしない方法ですが、
Linuxでは特殊な構成のハードウェアで無い限り、他のマシンのHDDを移植しても
起動時にハードウェアの変更が自動的に検出されて、いくつか質問に答えるだけで
普通に使える状態で起動できるようです。

今回、fsckを何周かさせてエラーが落ち着いたので、試しにやってみたのですが、
旧マシンが昔Dellで買ったCeleron（多分Northwood以前）＋
インテルチップセットのマシンで、新マシンがVIA PC1500という、
Windowsだったらドライバの問題で確実にまともに動作しないだろうな
という組み合わせでも普通に元マシンの環境が新マシンで立ち上がりました。

あと、旧マシンは再利用頻度の低いファイルの置き場所として使ってたり、
Subversionサーバー（つまり作業コピーがどこかのクライアントに存在する）
として使ってたり、今回は消えたらアウトなファイルが無かったため、
fsckを掛けまくりましたが、普通はそれでいくつかファイルが消えたりするし、
今回もその課程でいくつかのファイルが実際に消えたので、
まったくおすすめできません。


２．旧マシンのHDDをマウントするにはちょっと操作が必要

普通は１．の操作をするよりこの操作をした方がサルベージしやすいと思います。
新マシンに新しいHDDを取り付けてCentOS5.2をインストールし、
旧マシンのHDDをセカンダリに取り付けてマウントしようとしたのですが、
普通にはできませんでした。つまり

# mount /dev/hdb2 /mnt

とかの操作ができませんでした。
で、色々調べたのですが最近のRedHat系はLVMという、
パーティションの中にさらに仮想的にパーティションを切るような方法で
インストールされるらしく、そのLVMの中身をマウントするには少々
操作が必要になります。

基本的には、LVMの中のパーティションをアクティブにし、
# mount /dev/VolGroup00/LogVol00 /mnt
みたいな感じでマウントできるのですが、
デフォルトのままLinuxをインストールしてると、
起動中のHDDとマウントしたいHDDで
ボリューム名が両方VolGroup00とかでかぶってしまい、
操作できません。

ということで、HDDのボリューム名を変えるには、
まず、変えたいHDDのUUIDを調べて、そのUUIDを指定して
ボリューム名を変更するコマンドを実行します。
具体的には

# vgdisplay
— Volume group —
VG Name VolGroup00
・・・省略・・・
VG UUID mK5km2-IgeS-IJN9-wz4i-kR6T-6d6n-ozxFqe

# vgrename mK5km2-IgeS-IJN9-wz4i-kR6T-6d6n-ozxFqe OldVolGroup00

くれぐれも稼働中のボリュームの名前を変えないように！
多分エラーが出て実行できないとは思いますが。

あとは以下のようにしてアクティブにし、マウントするだけです。

# vgchange -ay OldVolGroup00
# mount /dev/OldVolGroup00/LogVol00 /mnt

最初LVMの存在さえ知らなくて
ちまちまと外付けHDDにコピーしてしまいました。
それ自体がバックアップになるから無駄じゃないけど、時間がすごいかかった。


３．MySQLの移行は簡単

/var/lib/mysqlをコピーしてくるだけで動作しました。
オフラインの移行は超簡単です。
オンラインは気を遣いますけどね。


４．Subversionの修復

リビジョンが1600弱に達してるリポジトリがあったのですが
どうも1450あたりのリビジョンデータが破損してるようで、
svnadmin dumpでもエラーが出てダンプできませんでした。

たまたま、リビジョン0-1500までのダンプデータがあったので
それを使いsvnadmin loadした後
# svnadmin dump /path/to/repos -r 1501:1600 –incremental > r1501-1600.dmp
で破損リビジョンに触れないように差分ダンプして
さらにsvnadmin loadで修復できました。

途中までのダンプデータがあったから助かりました。


５．Sambaでアクセスできない

どう設定してもWindowsからアクセスするとエラーが発生してしまうときは
SELinuxを疑った方が良いかもしれません。
# setenforce 0
でSELinuxを無効化したら何事もなくアクセスできるようになりました。
俺の3時間を返せｗ
まぁ、無効化しっぱなしもアレなので後日きちんとした設定をしたいと思います。