unoh.github.com

linuxで○○が壊れた時の対処法

Fri Sep 22 02:24:36 -0700 2006

こんにちは satoです。
障害の多くの場合はハードディスク障害ですが、実際障害が起きた際に、どのように復旧するかをケース別に書いてみようと思います。

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