FC2ブログ

にゃごにゃ小学校

本家(HP)作製のネタ、あるいは記事にするには寸足らずな話を日記兼用でアップします。

 パソコンのこと、というただし書きは、人命レスキューに興味のある人をがっかりさせないためです。

 木曜日から金曜日にかけて、ここ最近では記憶にないほど手間のかかるパソコンデータのレスキュー作業を行いました。これは、その記録です。

【ことのおこり】

 木曜日、仕事をしていると父からメールが入りました。「パソコンが立ち上がらない」。Windowsを使い、原稿の執筆やHPの頻繁な更新、メールでの質疑応答などを行うヘビーユーザーの父からは、こうしたパソコンのトラブルがよく持ち込まれるのです。
 状況を聞くと、起動の途中でエラーが発生してなにやらチェックしているが、途中でリブートしてしまう。それを何度やっても繰り返す、ということです。

 けっこう急ぎらしく、その日の夕方に芦屋の自宅からわざわざ一時間かかるうち(というかセカンドハウスにしている、うちのマンションの隣の部屋)まで来る、というので、私も早めに会社を出ました。

 さて、早速父のノートパソコンを見てみました。ウィルスに感染していたり、設定がおかしくなっていたり、と、概ねいつもWindowsの品質の悪さが原因のソフト的要因であるので、今回も甘く見ていたのですが、実際に見てみると、生易しいものではないことがわかりました。かなりの確率で、ハード的な障害です。

【データのバックアップとディスク交換、リカバリ】

 父が言うには、とりあえず、執筆中の原稿だけ助かればいい、ということでしたので、LinuxのブータブルCDを使って、それらのファイルをバックアップしました。
 ハードディクスの障害であるのはほぼ確実でしたので、たまたま私のモバイル用に購入したものの使えなかったため余っていた2.5インチHDDと入れ換え、リカバリディスクでリカバリし、バックアップデータを書き戻しました。その後、問題なくWinXPも起動しました。

【固まる父】

 これでOK、簡単なもの、と父に渡します。喜ぶ顔が見られるかと思いきや、しばらく触っていた父の表情が固まっていきます。「バックアップの必要なものは原稿のファイルだけ」ということを念押しして始めたリカバリであったのですが、実はメールやらHPのデータやら、最新のデータのうちで必要なものがけっこうあったらしいのです。
 よく考えずに返事したのか、いつもトラブルがあってもかなり原状に近い形で私が復旧するので、その程度には戻ると勘違いしていたのか、「ほかのPCのデータやバックアップを集めれば何とか…」という言葉も虚ろ。
 これは、やはりなんとしてでも環境ごと復旧するしかないと理解した私は、酒を飲むのを打ちきりにして、性根を入れ直してリカバリ作業に着手しました。

【症状と難航するバックアップ作業】

 幸いにして、今回は元のHDDは、交換したためクリアせずに残っています。このディスクに対してリカバリを行っていたらもう二度と復旧の手段はなかったので、不幸中の幸いでした。
 再度このディスクをノートPCにつけ戻して、まずパーティションごとのバックアップをトライ。しかし、異常に時間がかかるだけで、とうとうエラーが発生して中断。この時点ですでに夜中の3時。少しだけ睡眠を取り、金曜日の出勤は断念して、作業継続。
 LinuxブータブルCDでの作業で明らかになったのは、やはりハードディスクの障害。個々の障害の範囲はそれほど大きくないものの、あちこちでバッドブロックが発生するのです。通常の手段でのバックアップは不可能であることを認めざるを得ませんでした。

【あきれるほどに手間のかかる救出作業の開始】

 USB接続できる外付けの大型HDDはありましたが、ノートPC上での作業が非常に効率の悪いことは明らかでした。そこで、デスクトップ機に、2.5インチHDD→3.5インチHDD変換ケースを使って直接接続して作業を継続。
 方針としては、バッドブロックを避けて読みだしセーブ、バッドブロックの箇所だけはリストアしないように、元のレイアウトを維持したまま、新しいディスクに書き戻す、という、シュレッダーにかけた書類をテープで貼って回復するような手間のかかる作業となります。はっきり言って、これだけの手間をかけてやってくれる業者はどこにもいないかもしれないし、いたとしても新品のパソコン2~3台、もしかしたら十数台くらいは即買えるくらいの料金を取られるでしょう。

 最初、バッドブロックの一覧をコマンドbadblocksで取ろうとしました。しかし、いかんせん、バッドブロックの数が多過ぎて、コマンドに任せ切りにしていては一向に処理が進みません。とうてい一日や二日で終わりそうもない状況です。
 そこで、ddコマンドで元ディスクのデータを取り出しつつ、syslogをモニタして、エラー発生時のbadblockの位置を確認することにしました。そして、エラーが出始めたらすぐ強制終了し、そこからどこまでbadblockが続くのかも新たに打ったddコマンドなどで確認し、出なくなるところからまたデータ取り出しを進める、という作業となりました。
 バックアップ先のディクスが、USBでなく同じ内蔵IDE接続のHDDであるので、その分速度はうんと上がりますが、badblockを検出して、強制終了をかけたコマンドが実際に止まってくれるまでの時間は数分から十数分、そのbadblockの発生箇所も広い範囲にわたって半端な数ではないので、ほんとに手間のかかる作業です。

【書き戻し】

 書き戻しもddコマンドです。読み出すとき、badblockを避けて、skipとcountオプションで正常な範囲のデータのみを取り出します。そして、その取り出したデータを書き戻すときは、seekオプションで書き込み先のHDDの位置を指定してやります。
 結局のところ、badblockエラーの出るブロック群のデータは損なわれるわけで、それではちゃんとレスキューできないのでは、と思われるかも知れませんが、全体のサイズからすると数が多いだけでbadblockのトータルサイズはパーセント以下しかありません。しかもそのすべての範囲が使用領域であったわけではないので、結局ある程度のデータのロスやデータ化けは発生するでしょうが、致命的なものではないのです。幸い、スーパーブロックやファイルシステムのテーブル領域にはエラーはなく、データベースなどのクリティカルなデータでない、通常のパソコンとしてデータですから、まあまあ無視できる範囲の不一致と言えるでしょう。

【無事、レスキュー完了】

 ほぼ24時間をかけて取り組んだレスキュー作業も、なんとか完了しました。
 最後の難関は、そうして復旧したHDDをパソコンに接続して、ちゃんとOSが起動し、データやプログラムにアクセスができるか、ということです。寝不足の頭で膨大な作業をした後だしミスもあるかも知れず、もしうまくいかなければ、会社を休んでまで不眠で行った作業はなんだったんだ、ということになります。それにもまして、父は窮地に陥ります。
 しかし、神は見捨てませんでした。
 無事立ち上がったマシンは、ほとんど前と変わらない環境で、問題なく使用できたのでした。出版を間近に控えた父は、原稿のほか、出版に関連してやりとりした数多くの人達との大量の打ち合わせメールが復旧でき、ぎりぎり〆切に間に合う、と胸をなでおろしたのでした。

 実は、今回は上記の、元ディスクを上書きしないでいた、ということのほか、もう一つの幸運がありました。
 元のディスクが60Gだったのですが、交換したディスクが40Gしかなかったのです。しかし、元のディスクは40Gだけ利用するように私がパーティションを切り直し、残りの20GはLinuxを追加インストールできるように空けていたのです。
 もし、元のパーティションが40Gを超えるような切り方をしていたとしたら、今回の手段で復旧させるには、新しいディスクも40Gを超えるものを準備しなければなりませんでした。そうなら出費もかさんでいたし、時間的にもさらに一日かかったでしょう。
 そのうちに父にもLinuxを使ってもらい、Windowsの束縛を離れて幸せになってもらおうという配慮をしていたことが、思わぬ形で生きたのです。

 今回の事件、結局のところ、父に人徳があったんでしょうね。日頃の行いがいいのだと思わされる一件でした。
 もちろん、自分のスキルで、難しい局面の父を助ける機会が得られたのは、私にとってもとてもうれしいことであったのは言うまでもありません。

スポンサーサイト



コメント

コメントの投稿

Name
Title
E-mail
URL
Comment
Password
※入力しないと編集・削除ができません
 管理者にだけ表示を許可する

トラックバック

この記事へのトラックバックURL

http://questkpax.blog51.fc2.com/tb.php/313-978bef4e