ハードディスク・トラブルの巻

忘れもしない 12月4日、愛機のハードディスクが読めなくなった。実際は「読めなくなった」のではなくて「書けなくなった」からなのであるが、この顛末をリスク管理の教訓として記録しておこうとおもう。

事の起こり

普段は２４時間電源を入れっぱなしの愛機(AT互換機P5-166)であるが、打合せのため外出するので電源を落としていった。打合せが終わって電源を入れるといつものようにシステムコマンダーが表示され、ＮＴを起動する。

いつものように Visual C++ を立ち上げてコードをぽちぽちと書いてコンパイルをかける。しかし、なんやらエラーが表示されている。「ブラウズファイルが作成できませんでした」。最近 VC++ を 4.1 から 4.2 にアップデートしたので、そのせいかなと思い再度挑戦。しかし結果は同じ。

これはまずいな、と思い chkdsk をかけてみることにした。思えばちょっと前に .zip ファイルが CRC エラーを起こしていたことがあった。

CHKDSK がフリーズ

chkdsk を /F オプション付きで、何度目かに FAT ドライブ F: を検査しているとフリーズした。なにをやってもフリーズは解除されないので、やむなく強制ログアウトのはめになった。動かないものはしょうがない。

リブート時のシステム・コマンダーのエラー画面

我開発マシンはシステム・コマンダーを入れて Windows 95, Windows NT3.51J, WIndows 4.0US, MS-DOS のシステムを共存させている。今回のリブート時にもいつものようにシステム・コマンダーのメニューが表示された。しかしメニュー選択後見慣れないエラー画面に出くわした。「なんだこれは？ Write Protect のため書き込みができません？」。リトライを選択するが無駄な努力。やむなく Ignore を選んで抜けると、ＮＴはちゃんと立ち上がるのでひと安心。

ファイルマネージャーでダメ

しかし、安心も束の間。ＮＴ自体はちゃんと立ち上がったものの、今度はファイルマネージャーでドライブ L: を選んでもエラーが出てしまうのだ。我ドライブ L: というのは合計５００Ｍ程度のＮＴＦＳのストライプセットで、メインの開発用のソースが格納されているドライブだ。これが壊れると泣けること請け合いの重要なドライブレターである。すべてのディスク１に関係する NTFS ドライブは表示すらされない状態になっていた。

今まで見たことがないメッセージボックスで、慌てたのは言うまでもない。

(しかし、なぜか ドライブ F: だけは表示された。これについては後述する。)

ＤＯＳ窓で dir もダメ

何が起こっているのかいろいろ確かめるために ＤＯＳ窓で dir をしてみようと思ったのだが、これもだめ。

ディスクアドミニストレーターもダメ

ディスクアドミニストレーターを起動してみると、なんと（不明）の表示だ。

ドライブ K: と L: は NTFS のストライプセットであった。ディスク１の最初のドライブ F: はFATで、残りはすべて NTFS ファイルシステムであった。
ディスク１に関係するドライブがいかれていることがわかる。 しかし、区画情報はしっかり残っている。ストライプセットも生きている。（後でわかったのであるが、これはディスク１自体が書き込み禁止になっているので不明となった）

希望はある

しかし、希望はあった。なぜなら、ＤＯＳ窓（正確にはＤＯＳ窓でなく、ＤＯＳプロンプトなのであるがこのほうが呼びやすいのでＤＯＳ窓とする）で chkdsk はちゃんとした結果をレポートするからだ。chkdsk /F オプションをつけると最後にエラー表示がされるが、単にチェックだとファイル数などが表示され、ハードディスクが「まだ生きてるよ」といっているのである。

書き込み禁止

以上の症状を総合すると、ハードディスクがあたかもＭＯやフロッピーディスクのように「書き込み禁止」ノッチがＯＮされているような症状である。そう考えると筋が通る。あわてて Quantum VP32210 Capella のデータシートで確認すると、なんと Write Protect ジャンパーがある。しかし、再度確認してもちゃんとそのジャンパーは外してある。ともかく今まで動いていたわけだからジャンパーが勝手に動くはずもない。

また、他のＯＳの Windows 95, MS-DOS, NT4.0US でも書き込み禁止と出るので、ＯＳがらみのトラブルでない事がわかった。

NTFS ファイルシステムでは読み込みだけで書き込みされる

さきに、ファイルマネージャーでなぜか ドライブ F: は表示されると書いたが、この理由がわかった。ドライブ F: だけは FAT でフォーマットされており、その他のドライブは NTFS だった。 NTFS ファイルシステムはいつアクセスされたかを記録するために「読み出し」だけでも「書き込み」が行われるからであった。考えてみればそれもそうだが、この状況下では NTFS ファイルシステムをうらんだ。FAT ドライブである F: からは別の正常なドライブにファイルをコピーできたのだが、NTFS ドライブからは一切読み出せない。ファイルは残っているわけだから、これはなんとも言えないくやしさである。そこで、Windows 95 から NTFS が読めるツールというものをインターネットから探し出して試みたのだが、なぜか読んだファイルは壊れてしまう。致命的なのはストライプセットをサポートしていない。お手上げ状態。

つまり HDD が故障したわけだ

どう考えても、ＨＤＤがお亡くなりになったということだ。ドライブ装置自体に書き込み禁止がかかっているように見えるわけだから、何らかの原因でドライブ装置にライトプロテクトがかかってしまっている。まだ原因は定かでないが、機器自体に Write Protect 機能があるというのはここが故障することもあるということだ。なまじこんな機能は無い方がいいと思った。一応、ＨＤＤのそのジャンパーの電位を計ったりしたのであるが、無駄な努力に終わった。

大事なソースを救わねば

読めなくなったドライブ F: G: H: K: L: には大事なデータがいっぱい詰まっている。お仕事の開発ソースがもっとも高価かつ重要なのであるが、他にもＷＷＷサイトの元データやら各種ツールやプログラムなどわんさか大事なものが詰まっている。

取り返しのつかない再取得不可能なものは、開発ソースだ。我ＦＴＰサイトにバックアップは何世代か前のものがかろうじてあったので、最悪の場合、これから再スタートできるが、やはり現世代のものにするには結構な時間が必要となる。ここはなんとか最新のソースを救ってただでさえ必死こいているプロジェクトを復帰させなければならない。しかし、時間は容赦無く過ぎていくのではんばあきらめて古いソースで開発作業を再開した。

奇跡が起こった

というのも大袈裟だが、号泣している私にはそう思えた。あきらめて再び電源を落として寝ること１２時間。肩をを落としたまま再び火を入れる。するとどうだろう、ブート時のシステム・コマンダーのメニューからすんなり行くではないか。

ＮＴを立ち上げ、ファイルマネージャーを起動すると、あったあった、ファイルが見える。さっそく正常なドライブ装置の空きエリアにコピー！コピー！またコピー！。 この様子だと開発ソースも無事だろう。おーまいごっど。感謝感激。

しかしこの操作中も、システムはエラー・ダイアログを出しまくる。イベントログではこうだ。

実際はこの内容が別のエラーダイアログとして表示されるわけだが、NTFS ファイルに読み込みがいくとファイルアクセス日付を更新すべくＯＳは日付情報に書き込みアクセスを試みた結果、書き込みができないのでこのエラーを $Mft と各ディレクトリ毎に出してくる。 ひっきりなしのリターンキー操作だが、ソースが救えるとなると疲れも感じない。

しかし、合計２Ｇがぶっとんだわけだから、代替の２Ｇエリアはどこにもない。コピー先の空きエリアがなくなってくる。正常なドライブが NTFS ならば迷わず「圧縮ドライブ」にしてコピーを続行するが、とうとう空きエリアも尽きた。

そこで、トラブったドライブのひと区画をディスクアドミニストレータでパーティション削除をして正常なドライブを増やそうと考えた。ストライプセットである K: L: を待避させ、これを削除した。しかし、ディスクアドミニストレータは「書き込み禁止です」と共に不安にさせるメッセージをいくつか表示して画面から消えた。これは何度やっても同じであって、トラブったディスク１の方が書き換わらない。また、NTFS のストライプセットをいぢくると、選択の余地がないままリブートされてしまうのだ。

電源オン後数分間は書き込みができる

リブートだけではダメで、結局電源をいったん切って再度火を入れ直すことで最初の数分間は書き込みができることがわかった。これはＮＴが起動後すぐにディスクアドミニストレータで区画を削除するのが精いっぱいの時間なのである。それも毎回成功するわけではなく、何度かに１回成功する程度の頼りなさであった。

やっとの思いでストライプセットを解除し、正常なドライブを新たに作成し、それも NTFS 圧縮ドライブにしてなんとか重要なファイルを救うことができた。

Windows NT は、起動時にエラーでなければ後でエラーになっても動作が続行できる。リブートしたら次回読めるかどうかわからないので出来るだけ救えるものはその場でやっておくことだ。実際、次のリブート時には読めなくなった。

このトラブったドライブはいまだにこの状態で、やはりお亡くなりになったようである。

教訓

人は病気になったときに健康の有難さを知るが、コンピュータもまったく同様だ。いままでハードディスクがまるごとイカレル出来事はプログラマー生活十余年の間に幸か不幸かなかった。せいぜいソフト的なクラスタやＦＡＴのトラブルだったので、解析ツールなっかを使って復帰してきた。しかし、今回は機器のトラブルであったのでお手上げになってしまった。

以前はソースコードをフロッピーに移して銀行の貸し金庫に入れていたのであるが、あれは経験のある人にはわかってもらえると思うが、いちいち面倒なのでそのうちやめてしまった。その代わりに .zip でパックして別ファイルとしてバックアップを作成し、保存していたのであるが、今回はその保存先もいかれてしまったので無かったのと同じになってしまった。

唯一活躍したのが、我バーチャルドメインサーバー（アメリカにある）に転送しておいたバックアップファイルである。こうゆうのはいざというとき重要な働きをしてくれる。

注意しても、同じきょう体内にあるどの物理ドライブがどの論理ドライブレターになっているかなんて管理できない。重要なのは見かけ異なる装置に分散バックアップすることである。昔ファイルサーバーが実はあったのだが、残念ながらクラッシュしたときには無かった。ＬＡＮで物理的に隔離された先にバックアップが必要だ。

しないといけないなとつくづく痛感させられました。また、見てわかるという点では、内蔵した SCSI ドライブからの BUSY/FAULT 信号線はできるだけ LED に繋いでアクセス状態を見れるように（つきっぱなしがチェックできる）したほうがよい。ことごとくあるディスク装置を使用しないようにしてもブート時やＮＴ起動時に時折点燈するのがわかる。

あと、バックアップ対象となるファイルは開発のソースコードであることはもちろんだが、テスト用として書いたソースも大変重要なことに気づいた。テスト用とは、例えば、タブコントロールをインプリメントしようとする場合にほんちゃんのプログラムに手を加える前に単独のテスト・アプリケーションを書くわけであるが、そのテスト用ソースである。これが残っているのと残っていないのとでは開発効率が圧倒的に違う。こうゆう一見ゴミコードもとても重要であることがわかった。本当に不要なコードならが、作業の合間に自ら消去しているのである。

今後、必要性を痛感していること

ということだ。今回の騒動で私は数年歳を食ったように感じる。トラブルは、忘れた頃にやってくる。結果的にファイルを救えたのは奇跡的でありまた、今後トラブったときには救えないだろうから、有難いトラブルでもありました。