- CONTENTS -
|
2004年04月の日記です
呪われているのか？ 2004-04-01 19:38:01 COMP
日記に書いたように昨日ルーターが不調になった。
復旧してやれやれ…と思ったのもつかの間、今度はメインマシン (WinXP) が起動できなくなった。
「\WINDOWS\SYSTEM32\WINDOWS\CONFIG がないよ。インストールCDの最初の画面でRを押して復旧できるよ」ってな感じのメッセージが出たので、そのとおりにしてみる。
が、これは「復旧できる」なんて話ではなく、単純に DOS に降りただけ。なにをどうすればよいのかわからない。
ないといわれたファイルは、確かになかった。が、CONFIG.SAV というファイルはあった。
名前からして、これはセーブされたバックアップファイルなのだろう。CONFIG にコピーして再起動してみる。
お、起動画面になった。修復されたか…と思ったら、いきなりインストールの途中から始まった。
どうやらこのファイルは「何をしていたか」を WinXP に指示するファイルで、バックアップは「前回インストール時の途中」のものだったようだ。
仕方がない。とりあえず、最後までインストールを終わらせてみる。
再起動。ネットワークの設定などを聞かれる。
…が、ここでハングアップ。なぜか先に進まない。
困った、これでは仕事ができないではないか。
---
そもそもこのマシン、WinXPのインストール時から調子がおかしかった。
Win2000では普通に使えていたのだが、WinXPと相性が悪いのか？
自作マシンだから、それもありえない話ではない。
実は、いままでにも何度か動作がおかしいことがあった。
なんとか復旧できたとしても、こう不安定では仕事にならない。
というわけで、思い切って新しいマシンを見に行くことにする。
急な出費で痛いのだが、仕事で使っているのだから仕方がない。
今まで買うつもりもなく、どんなマシンがいいのかもわかっていなかった。
前のマシンは Athlon で「失敗した」と思ったこともいくつかあるので、今度は Intel マシンにしよう。
Cerelon でもいいのだが、そうなると実は今までのマシンよりも非力になってしまう。
それも悔しいので、やはりPentium4 で。
何店か見てまわり、いろいろ迷った挙句VAIO RZ55を購入。
なんか、仕事で使う（プログラム作成…ほとんどの時間はテキストエディタを開いているだけだ！）にはスペックが高すぎる気もするのだが、多少は趣味にも使いたいので…
まだ環境構築は終わっていない。仕事に使うための最低限の環境構築を急がねば。
この記事単体へ
やっぱり呪われているらしい 2004-04-09 11:52:27 COMP
つい先日ルータに使用している Linux とメインマシンの WinXP が相次いで故障したのだが、今度は仕事先のサーバーが故障した。
第一報が飛び込んだのは、昨日の夜７時半ごろ。
夕食を食べようとしていたところだったが、サーバー担当者からの「データベースサーバーのハードディスクが壊れました」という知らせで、食事どころではなくなった。
無停止で運用する必要があったため、最近のバックアップは取っていない。
（サーバーを停止しないとデータベースのバックアップは取れない）
そういうクリティカルな部分なので RAID を組んであったのだが、その RAID 装置自体が壊れたらしい。
普通なら fsck する部分でディスクエラーとなり起動できない…と言われたので、「先日のルータ故障と同じだ」と直感。
「別のマシンに接続して、ext2 として mount してみてください」と指示。
---
最悪の状況を考え、データがすべて壊れた場合に最善の復旧方法を用意する。
からっぽのデータベースを作って再スタート、ということだが、データベースはその構造も含めて長期にわたっていじり続けているので、一発で同じ構造が作れるかどうか確認。
案の定、細かな問題がある (^^;;
構造作成のスクリプトをいろいろ手直し…
10分ほどたって再び電話。
「mount しようとしても壊れてるといわれます〜」
「fsck.ext2 しました？」と聞くと、「あぁ、そういえばしてない」とのこと。
サーバ担当者も気が動転している。「もうすこしやってみます」といって電話は切れた。
呼び出されるかもしれないので、夕食をかき込んでおく。
３度目の電話は８時ごろ。
「mount はできましたが、やはりデータが壊れているようです」
うぅむ…仕方ない。「今すぐいきます」ということで電話を切った。
うちからその仕事場までおよそ２時間。
この間に進展があった場合、僕がすぐプログラムを出来る環境にいないと時間のロスだ。
しかし、どうやら問題は深刻で、２時間では解決できないだろう。
---
10時ごろに到着したが、状況は芳しくないようだった。
HDD １台からはデータを吸い上げているが、いくつかのデータは壊れている。
特に、ユーザー管理データなど、クリティカルなものが壊れているのが痛かった。
壊れたデータはなにで、壊れていないデータはなにで、必要なデータはなにか…という洗い出し作業を始める。
ユーザー管理データが壊れているのなら、それに関係したデータはすべて意味を失う。
しかし、コンテンツ運用に必要なデータは、ユーザーとは関係がない。これらはすべて残っているようだ。
これはありがたい。少なくとも、コンテンツの運用は復旧できる。
データを吸い上げ終わり、もう一台の HDD を mount する。
壊れている箇所が別で、合わせて復旧できれば…と望みを託すも、こちらは完全に壊れていて、mount すらできない。
決断の時…完全復旧はあきらめ、データは破損したがコンテンツの復旧を急ごう。
この時点で、深夜12時近かった。
方針が定まれば後は早い。
ユーザーへのお詫び文章を用意し、表示できるようにプログラムする。
既存のユーザーの一部で、ユーザー側がデータを持っている場合がある。
これらの場合、こちらのユーザー管理データと不整合が生じて問題が起こることがわかったので、これの対処プログラムも作り上げる。
１時過ぎには復旧の準備が整ったが、これで大丈夫なのかがわからない。
現在、ユーザーにはトラブル告知の HTML ページを表示しているが、このままでは自分もコンテンツに入れず、動作確認できないためだ。
ここに条件的に穴を開けるプログラムを作り、ひととおりの動作確認。
復旧の準備が出来、ユーザーに公開したのは1時45分だった。
---
話はこれで終わりじゃない。
突貫作業で、案の定問題点が出る。
これを細かく修正する。全部終わったのは３時ごろだった。
サーバー担当者と、今後の方針について対策する。
現在の方法ではサーバーは停止できず、データベースのバックアップも取れないのだが、ディスクを二重化するRAIDではなく、サーバーの二重化をうまく行えば、片方を停止しても問題は出ない。
データベースなので停止している間に不整合が起こっては困るのだが、これについてはうまい方法もある。
また、同じものが２台あることになるので、トラブルの際にはすぐ切り替えることも出来る。
バックアップを取るためだけにサーバーを１台用意することになるのだが、今後はこの方針で行ったほうがいいだろう。
空が明るくなり、電車が動き始めたので帰宅。
すこし仮眠を取ったが、目が覚めたのでこの日記を書いてみた。
この記事単体へ
戻る
|
|