当該機には、ここSnap.ShotのためのZopeサーバやモントラのためのMySQLサーバなんかが乗っています。
加えて、メインのnamedサーバや、フィルタつきMSAを含むメールゲートウェイなんかが乗っていました。
あとは、アーカイブ系のメールを溜め込むためのCourier-IMAPサーバくらいかな。
なので、さほど重要な機能は乗せていないつもりでいたのですが、実際に無くなってみると、仕事にも差し支えるほどの不便さ。
復旧しないわけにもいかず、とりあえず再起動。
まず、障害のあったディスクを、あらためてread-onlyとしてmountします。
続いてそのディスクを親として、/usr,/bin,/sbin,/etcあたりを丸々コピー。
多少コピーに失敗するのはRPMで補うつもりでいましたが、実害のあるほどの破損は無いようなので、とりあえず放置。
/home以下は、とりあえず必要最小限だけのコピーに止めます。
ヘタにcp -pidR /home /mnt/newdisk/なんてやってしまうと、どのデータがサルベージ出来ているのか、収拾がつかなくなります。
そうでなくても、今やあらゆるファイルがデカい訳です。
すべてが今直ぐ必要とは考えにくいので、とりあえずサーバの機能を復旧させてから、裏でゆっくりサルベージすればよろしい。
もちろんこれには、普段より必要な成果物はバンバン複製をとってあるという前提が必要です。
何の対策も取っていないようなファイルは、たぶん重要度も低いであろうという思い切りも重要です。
うっかりしていた点がひとつだけ。
近年はZopeまわりのバックアップをロクに取っていないようでした。
ZODBの一部が壊れていた日にゃぁ、Snap.Shotの全記事をロストしてしまうところでした。
やっぱりファイル（ディレクトリ）単位でコピー出来るか否かというのは、保守の面ではすこぶる重要だなと思う次第。
それこそ、ZODBと言わずSquishdotと言わずZopeと言わず、早いところガンガン捨てたいのですが、未だ、志、果たせず。
ともあれ、なんとか半日程度で、とりあえず動く状態だけは再現できました。
しかしこれでもまだまだ甘いナァというのが正直な感想です。
まだ時間的に余裕があったので、直ぐに対応できましたが、これが納期直前の炎上中だったらと思うとゾッとします。
普段より、サーバの1コくらい壊れても、とくに支障無く仕事できるくらいの代替システムは準備しておくべきだと痛感しました。
|
