Failure management(2)

本館( http://whitewing.bitter.jp/ )がサーバー障害で一時止まり、仮復旧にはこぎつけたものの、プロバイダ( http://www.rim.or.jp/ )側の障害対応は今のところ中身が空の仮設Webサーバーを用意しただけのとしては使えるようにした、というところで止まっている。めどが立っていないということだ。
復旧作業でいくらかCGIのプログラムを動かしていたが、障害発生前は確実に動いていたと思われるCGIスクリプトの出力が途中で止まってしまうところをみると、仮設サーバーはメモリや処理能力も本来のものよりは小盛りなのかもしれない。


今回のようなハードディスクの障害は、用途に限らずサーバーの類を扱う世界では避け得ないものである。世間様一般では、予算と信頼性とアクセス速度のバランスを見ながらそれなりの障害対策を取っている、ということになっている。
比較的簡単なところではRAIDなどを使って複数のディスクにデータを分散させたり、サーバーそのものを2系統用意して適宜データの同期を取っていつ障害が起きても交代できるようにしておくなどの手法がある。
これと並行して適当な周期でデータのバックアップを適当な形式で取るようにしておくと、生命や安全や財産にかかわるような特殊な用途でない限り、大半のサーバーにとっては十分な障害&操作ミスの対策となる。
プロバイダ( http://www.rim.or.jp/ )や親玉( http://www.ejworks.com/ )がどのような方針でどのような装置類を使って設備を構築していたのかは知る由もないが、これだけの期間が経ってもデータの復旧が全くできていないところをみると、定期的なバックアップをサボっていたのではないか、という気がしてくるのだ。
対象となるデータの量にもよるが、バックアップを取ることはそんなに難しい仕事ではない。毎回ハードディスクの中身全てをコピーする必要はなく、新規追加されたものや更新のあったファイルだけのバックアップを取るだけでもそれなりの効能はあり、その方法はいくらでもある。データ量にもよるが、定期的なデータのバックアップは大学の研究室の片隅にあるような老朽ワークステーションでも片手間かつ短時間でできる仕事である。
しかし現に、本館( http://whitewing.bitter.jp/ )側のサーバーは仮のものとなっており、実況中継( http://whitewing.bitter.jp/live/ )のバックアップは7月後半止まりのままとなっている。
サポートデスクのお知らせは更新されたが、障害復旧のめどが立っていないという点では情報の更新はない。早期の対応を期待する方が無駄に思えてきたということで「実況中継」7月後半以降の記事の復旧作業に着手。
本館のログ復旧作業は、書き込んだ際に自動で送るように設定しておいた書き込み通知のメールからログをでっち上げてやるという方法も可能だったが、別館( http://blogs.dion.ne.jp/whitewing/ )のログから本館用のログをでっち上げた方が楽であることに気づき、方針変更。
別館のログはMT形式で保存されているので、以前作った「MT形式ログから自作CGI形式のログをでっち上げるツール」を使えば比較的短時間で作業は終わる…はずだったが、処理能力などのサーバー周辺勝手が違うのか、一筋縄ではいかず、ツールの調整に1時間程費やしてしまったが、ひとまず完了。
これで見かけ上は何事もなかったように見えるところまでは漕ぎ着けたが、時折見ていたサイトの内RIMNETドメインのものの大半が、障害のお知らせまたは404 not foundの状態のままとなっているのが痛々しい。
いっそのこと別館( http://blogs.dion.ne.jp/whitewing/ )と本館( http://whitewing.bitter.jp/ )の立場を入れ替えてみようかとも考えたが、別館側は別館側で「DION」から「auOne net」への看板掛け替えを予定しているとかで、今後が微妙だ…
テキスト庵( http://www.spacehorn.com/text/ )の登録の迂回措置はもう暫く継続としておこう。