障害の多くの場合はハードディスク障害ですが、実際障害が起きた際に、どのように復旧するかをケース別に書いてみようと思います。
hdd のセクタが壊れた
/var/log/message等に kernel: hda: dma_intr: status=0x51などど表示されているとハードディスク障害の可能性が高いです。
badblocks -vs -o hda1.sector /dev/hda1
(かなり時間がかかる)とやると 不良セクタが書き出されたファイル hda1.sector ができます。
fsck -l hda1.sector /dev/hda1
とやると不良セクタを使用しないようになります。いずれにしても早めの交換をお勧めします。
memoryが壊れた
http://blog.miraclelinux.com/mita/cat218683/index.html
に詳しいやり方が書いてありましたので参照しました。memtestであらかじめ不良領域を調べておいてブート時にメモリを使用しないようにする方法です。いずれにしても早く交換することをお勧めします。
svn のリポジトリが壊れた
svn admin recover リポジトリのディレクトリ
とかで復旧できる場合もあります。いろいろがんばってできないときはあきらめて、ダメなときは前日のバックアップから復旧しましょう。無い場合はsvn importしましょう
Berkeley DBはなんかよく壊れる気がするので、最近はfsfsを使用するようにしました
svnadmin create --fs-type fsfs と指定すれば fsfs形式になります
postfixのメールボックスが壊れた
alias等で その人メールの転送先を一時的に変えて メールファイルに sato に対して
formail -b < sato > sato.new
とやって 一旦エクスポートして、元ファイルと置き換えましょう。
mysqlのテーブルファイルが壊れた
マスターはスレーブからスレーブはマスターから復旧しましょう。無い場合、MyIsamテーブルの場合は repair tableコマンドで修復することができます
http://dev.mysql.com/doc/refman/4.1/ja/repair-table.html
InnoDB形式のデータが壊れた場合は SELECT INTO OUTFILE でファイルに一旦吐き出して、 LOAD DATA INFILE でリストアします。エラーが出る場合には my.cnf の innodb_force_recovery の値を変えてダンプしてみます
http://dev.mysql.com/doc/refman/4.1/ja/forcing-recovery.html
--
経験的にハードウェア障害の原因は
HDD 70%
NIC 10%
電源 10%
その他 10%
といった感じです。
メモリーのテストは memtest で行うことができますが、詳細なHDDのテストは HDDのベンダー毎に違うのであらかじめツールを入手しておきましょう。
Seagate http://www.seagate.com/support_ja/disc/drivers/discwiz.html
Hitachi(IBM) http://www.hgst.com/hdd/support/download.htm