雑記

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|
2007|01|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|09|11|
2009|02|03|05|06|07|08|10|11|12|
2010|01|03|04|05|06|07|08|09|10|
2011|05|06|09|10|
2012|03|07|09|12|
2013|01|02|04|05|07|08|10|11|
2014|04|05|08|10|12|
2015|01|05|
2016|09|

2006-01-24 [長年日記]

サーバ障害

周りでバタバタとしたせいか、昨日になって、サーバラックから30分おきぐらいに、靴底に画鋲が張り付いた靴で廊下を歩いたときのような、カツーンという音が聞こえてくるようになりました。音源をたどるとこのサーバです。明らかにまずい兆候なので、まずは設定ファイルをバックアップ。続いてデータをバックアップしようとしたら、しばらくしてHDDがtimeoutを起こしてOSごとハングアップ。連続アクセスなどの高い負荷を長時間かけなければとりあえずは動くので、起動したままHDDを購入にお店に走りました。うちの会社のサーバもかねているので、5時まで待ってデータの移動開始。

[FreeBSD] 障害復旧・データサルベージ編

HDDを近所のPCショップで\1980で投げ売りされていた変換アダプター(IDE-3525)を使って正常なPCに接続して作業開始。案の定というか、いったんディスクへのアクセスができなくなると、コピーコマンドはもとより、sync や shutdown も機能しません。活線挿抜に望みをかけますが、OSがpanicして再起動しました。しょうがないので機械的にリセットをかけると、再起動時のfsckでコピー先の大量のファイルが消えます。被害を最小限に抑えるために編み出したノウハウは、次のようなものです。

  1. コピー中にHDD止まる。
  2. 別のコンソールでshutdownコマンド実行。プロセスの終了処理が実行され、sync処理前で止まる
  3. HDDをUSBコネクタから抜く。
  4. syncが始まる。retryを繰り返すが当然失敗。しばらくするとあきらめてリブートがかかる
先にshutdownコマンドを実行するのがミソで、バックアップ以外のプロセスにまつわるfsckエラーが無くなります。

止める方法が確立したので、いよいよデータのサルベージ。I/Oエラーが出る場所はまちまちなので、円盤上には正しいデータが残っていることが期待されます。ただし、dumpコマンドでバックアップを取ろうとすると最後まで行かないので、細かいディレクトリ単位でバックアップしました。

  • 1回目はtarを使ってできるところまでコピー
    # cd /src/usr
    # tar cf - local/etc | tar xvpfC - /dst/usr/
  • tarが運悪く途中で止まった場合、再起動した後、rsyncを使って残りをコピー
    # rsync -acut /src/usr/local/etc/xxx/ /dst/usr/local/etc/xxx
2回目以降にrsyncを使うのは、チェックサムオプションによりデータの完全性を保証するためです。

しばらく上記方法でちまちまとコピーを取っていたのですが、何回かやっているうちに、アクセスが止まった直後にHDDをちょっと動かすと復帰することを発見。HDDから聞こえる音から、円盤の回転が落ちるか止まるかした結果timeoutしているようで、HDDを傾けることによって止まった円盤の回転が再開している感じでした。これで状況は一変し、tarで一気にバックアップ、その間、HDDを持ってひたすらゆっくりと揺らすという、はたからみると危ない人モードに。動作中に揺らすというのはちょっと怖いですが、壊れるような衝撃を加えるわけではないので、まあ大丈夫だろうと判断しました。

[FreeBSD] 障害復旧・リカバリ(失敗)編

成功した方法から書くと、新しいHDDにOSをインストールした後、サルベージしたデータをコピーして終了です。で、以下にはうまく行かなかった方法を後学のためにメモ。

  1. IDE-3525に新しいHDDをつないで、バックアップマシンに接続
  2. /stand/sysinstallを起動してFdiskでスライスを作成し、wで書き込んでからいったん終了
  3. 再度/stand/sysinstallを起動してDisklabelでパーティションを作成
  4. バックアップしたデータを各パーティションにコピーし、/etc/fstabを新しいHDDのパーティションにあわせて変更
  5. HDDを繋ぎ直して起動
  6. Missing operating system で起動せず
  7. 上書きインストールを使ってMinimum構成インストール。状況変わらず。
  8. /パーティションだけnewfs yesとしてMinimumインストール。状況変わらず
  9. 通常インストール(newfs no)。状況変わらず
  10. 通常インストール(newfs yes)。状況変わらず
  11. HDDを取り外してバックアップマシンに繋ぎ直し、MBR消去
    # dd if=/dev/zero of=/dev/da0 bs=1024 count=1
  12. HDDを再び接続してクリーンインストール。MBRにはStandard MBRを選択。HDDにアクセスした瞬間にリセット、再起動を繰り返す。
  13. MBRを再消去して、FreeBSD

    Boot Managerを選択してクリーンインストール。正常起動

  14. すべてのデーモンを止めて、/ パーティション以外のバックアップデータをコピー。/ パーティションについては、いったん/var/tmp/root以下にコピー
  15. シングルユーザモードに移行して/パーティションのデータをコピー。/etc/fstabを編集して再起動
  16. 元の状態に戻っていることを確認
2.で書き込んだMBRが悪かったようなのですが、止めてもう一度確認する余裕は無いのでとりあえずはこれで作業完了ということにしました。作業終了時刻は24日11:00。

とくダネ!

復旧作業のBGに流していたんですが、小倉氏が中立の立場を守るために、これまではライブドアに対してネガティブなコメントができなかったとか、ライブドアを散々非難していました。ところが、その直後に伝えられたヤマハの事件に対して、「ヤマハと検察の認識の違いだったんだろう」「あんな立派な企業が不正と分かっててあんなことをするはずが無い」「なぜ、政府(経産省)は告発する前に照会や確認をしなかったんだ。そうすればヤマハも問題に気づいて行動を改めることができたはずだ」とか何とかやけに張り切って擁護していました。で、ふとそれって主語をヤマハからライブドアに替えても成り立つよなぁと思ったり。小倉氏に限らず、中立という言葉を擁護はいくらやってもok、非難はタブーという意味だと(わざと?)勘違いしている人が多いような気がします。

あと、フジに限らず、堀江氏は一連の行動に対して不正だったとは思っていないと言い、他の幹部は、一連の行動をやった事実を認めていることに関して、堀江氏は不正への関与を否認、他の幹部は不正を認めているというミスリーディングしているのには、明らかな悪意を感じます。ライブドアが行っていた株価の引き上げ手法がえげつないのは解説報道をみると良く分かるので、へんな情報操作に走らずに事実関係を正しく伝えてくれれば十分だと思うのですが。