2006年4月9日日曜日

magicrescueで壊れたHDDからデータだけ救出【最終手段】

先日、BSQR最後の日でしたが、ある方のノートパソコンのハードディスクが、壊れてしまいました。



そもそもWindowsが起動しません。急いで別のPCに接続して、読めるデータだけすぐにコピーしようと思ったのですが、Windowsのエクスプローラで見ると、ドライブは表示されているものの、中身を表示させようとしても、エラーがでて、ファイルやフォルダにはアクセスできません。



そしてディスクからは、シャカシャカシャカ・・・ず~~~と変な音がつづけてなっていて、ディスク内のデータがまともに読めない状態です。



どうやら、これは、パーティション情報がとんだとかいうレベルの障害ではなく、読めないセクタが大量に存在し、ファイルシステムの管理情報も読めないし、そのほか、ファイルのデータ本体の方でも、読めなくなっているものがあると思われます。



今回、最後の手段として、「magicrescue」というツールを使って、ディスク内の全セクタを読み出して、データファイルとして復旧できるものだけ復旧させてみました。





■ 急いで、慌てて、慎重に、HDDの全データのコピーをとれ!!



  • エラーがでて読めないファイルがあったり、


  • Windowsが起動途中でエラーになってしまうとか、


  • ひどくなってくると、Windowsのロゴが出る前にエラーになってしまうとか、


  • ハードディスクのアクセスが、妙に時間がかかるとか、


  • シャコシャコシャコシャコ・・・と、いつもとは違う音がしている(エラーが発生し、リトライを繰り返しているとき、一定のテンポでアクセス音がなりつづけます)、


そういう症状が見られるときは、ハードディスクが壊れかけている可能性があります。



そんなときに、ディスクが正常かどうかをチェックするソフトを実行したりすると、「くたびれたディスク」をさらに酷使させてしまい、より重症化させてしまう恐れがあります。

これは今回起きた話です。「このパソコン、調子が悪い」といわれて、様子を見たときは、まだ、Windowsが起動途中でコケル程度でして、まだCドライブの内容はある程度読めていたようです。しかし、次に、もう一度起動しようとしたら、「起動可能なディスクがねーよ」エラーになりました・・・ あーあ、1回だけ、余計なことをしたがために、最悪な事態を招いてしまったのでした。チャンスは1回だけだったのでした。幸運の女神には前髪しかない、とかいう話を思い出しますね。





早急に、そのディスクを取り出し、別のパソコンに接続して、ディスク内の全データを吸出し、別の正常なディスクへコピーします。



そして、復旧作業は、コピーしたほうを使って行います。必要ならば、コピーのコピーをつくっておけば、失敗しても、元の状態にもどせますね。



Unix系のOSでは、ddというコマンドで、ディスクの全データを読み出すことができます。



まずは、取り外した問題のHDDを、IEEE1394やUSB2.0で接続する外付けHDD箱にいれて、FreeBSD 5.4-STABLEなパソコンへ接続してみました。



すると・・・

(da0:sbp0:0:0:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0
(da0:sbp0:0:0:0): CAM Status: SCSI Status Error
(da0:sbp0:0:0:0): SCSI Status: Check Condition
(da0:sbp0:0:0:0): MEDIUM ERROR csi:49,52,45,0 asc:4b,0
(da0:sbp0:0:0:0): Data phase error
(da0:sbp0:0:0:0): Retrying Command (per Sense Data)

というようなエラーメッセージがたくさん表示されました。ああ、これは重症です。



とりあえず、パーティション情報だけはfdiskコマンドで表示することはできました(だから、エクスプローラでドライブだけは認識されていたのでしょう)。



# fdisk da0
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=2432 heads=255 sectors/track=63 (16065 blks/cyl)



Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=2432 heads=255 sectors/track=63 (16065 blks/cyl)



Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX)
    start 63, size 39070017 (19077 Meg), flag 0
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>



ddコマンドで、エラーのあるHDDからデータを読み出すときは、「conv=noerror,sync」というオプションをつけます。noerrorは、エラーが発生しても処理を継続するという意味です。そのままだと、エラーがあったときのデータは読み捨てられてしまうので、syncも指定することで、エラーがあったところは、すべてゼロなどダミーのデータで置き換えます。これで、全体のデータ量としては、もともとのデータ量を維持したままにできます。



  • if=~は、読み出すHDDのデバイス名。今回は/dev/da0。


  • of=~は、書き出し先のファイル名。今回は、/usr/tmp/da0.datというファイルへ、ディスクイメージを保存させるようにしました。


  • bs=~は、入出力の単位とするデータサイズを指定するのですが、たぶん間違っているような気がしてならないのですが、とりあえずうまくいっているので、bs=1m、つまり1メガバイトを指定しています。小さい値にすると、すごく時間がかかります。


  • (2007/09/10 追記) bs=1mだと、セクタがだんだんとずれていってしまうことがありました。bs=16kだと、うまくいったんですが・・・すみませんが、なぜそうなるのか、よくわかりません。


実行例は、こんなかんじ。



# dd if=/dev/da0 of=/usr/tmp/da0.dat bs=1m conv=noerror,sync
dd: /dev/da0: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 9.657693 secs (0 bytes/sec)
dd: /dev/da0: Input/output error
dd: /dev/da0: Input/output error
1+0 records in
1+0 records out
1048576 bytes transferred in 19.174362 secs (54686 bytes/sec)
dd: /dev/da0: Input/output error
dd: /dev/da0: Input/output error
2+0 records in
2+0 records out
2097152 bytes transferred in 28.877014 secs (72624 bytes/sec)
dd: /dev/da0: Input/output error
(以下省略)



約18ギガバイトの容量のディスクでしたが、リードエラーが頻発して、リトライが繰り返されるために、全部読み出し終わるまで、1昼夜くらいかかりました





■ 今回の壊れ方について



今回は、Windowsのエクスプローラで、ドライブの中身を表示しようとしても、まったく表示できない状態でした。



これだけでは、必ずしもそうとはいいきれませんが、これは、ファイルシステムの管理情報が、吹っ飛んでしまっている状態のようです。言わば、本の目次や索引が消えてなくなってしまって、かつ、全部のページがバラバラにちらばっていて、どこにどの情報があるのか、まったくわからなくなってしまったような壊れ方といえます。



そこで最終兵器として使ったのが、magicrescueというツールです。バラバラになっている全データを総なめして調べ上げて、「どうやらJPEGファイルらしい」とか、「どうやらZIPアーカイブファイルらしい」とか思われるデータをつなげ合わせて、ファイルとして吸い出してやろう、という戦法です。



細かい話になってしまいますが、ファイル名と、ファイルのデータとは、別々に保持・管理されているため、magicrescueで吸い出したファイルは、もはや元のファイル名がわからなくなってしまい、英数字だけの無意味なファイル名になってしまいます。



もしも、ファイルシステムの情報がいくらかでも残っているならば、magicrescueではなく、「Sleuth Kit」というツールで、もうちょっと賢い方法でファイルを復旧できるそうです。この方法だと、元のファイル名もきちんと取り戻すことができるようです。勝手な想像ですが、たぶん、ノートンのNorton Disk Doctorと同程度のことはできそうなツールのようです。



Sleuth Kitも、FreeBSDのportsになっていて、

/usr/ports/sysutils/sleuthkit/

にあります。ただこのツールは、コマンドラインで使うツールで、けっこう専門知識がないと、使いこなせないかもしれません。というときのために、Autopsyという、Sleuth KitをGUI化するツールもあります。これも、

/usr/ports/sysutils/autopsy/

にあります。



今回、ちょこっとautopsyを試してみました。GUIといっても、Webブラウザで使うようになっていました。残念ながら、問題のディスクは、NTFSとして認識してもらえないくらいに壊れていたので、autopsy、sleuthkitでは、太刀打ちできませんでした。



というわけで、最後の武器、magicrescueを使うことに至ったわけです・・・



● 各ツールのウェブサイト



Sleuth Kit
http://www.sleuthkit.org/



Autopsy
http://www.sleuthkit.org/autopsy/



Magic Rescue
http://jbj.rapanden.dk/magicrescue/





■ magicrescueのインストール



magicrescueは、FreeBSDのportsになっていて、

/usr/ports/sysutils/magicrescue

にあります。make install cleanで、いつもと同じ要領でインストールします。





■ magicrescueを実行する



こんな感じで、magicrescueを実行します。



# magicrescue -d /usr/tmp/output -r avi -r gzip -r jpeg-jfif
-r jpeg-exif -r mp3-id3v1 -r mp3-id3v2 -r png -r zip
-r msoffice /usr/tmp/da0.dat

(見やすいように途中で改行していますが、もともとは1行です)



  • 「-d ディレクトリ名」で、吸い出したファイルの保存先を指定します


  • 「-r なんとか」は、recipe(レシピ)というものを指定します。レシピは、/usr/local/share/magicrescue/recipes/にインストールされています。


  • 最後に、ディスクイメージファイルを指定しています。実は、ここにはディスクのデバイスファイル名を指定してもよいことになっているのですが、なぜかうちのFreeBSD 5.4-STABLEではエラーになってしまって、ちゃんと動きませんでした。Linuxだとうまくいくのかも?!


レシピというのは、AVIファイルとかJPEGファイルとか、データファイルごとに用意されるもので、データの特徴とか、復元するための情報などが一定のルールで記述されたもののようです。自分でもレシピを用意できるらしいですが・・・難しいだろうな・・・



最初から用意されいてるレシピは以下のとおりです。



# ls /usr/local/share/magicrescue/recipes/
avi             gpl             jpeg-jfif       msoffice        zip
elf             gzip            mp3-id3v1       perl
gimp-xcf        jpeg-exif       mp3-id3v2       png



*.avi、*.gz、*.jpg、*.zip、*.png、*.mp3などに対応でき、msofficeは、Microsoft Officeのデータファイル、つまり*.doc、*.xls、*.pptなどのことのようです。



magicrescueを実行すると、いろんなメッセージがたくさん表示されます。

/usr/tmp/output/0000030E6800-0.jpg: 60962 bytes
Found jpeg-jfif at 0x30FE200

これは「JPEGファイルらしきもの」を見つけたよ!とか、

Found zip at 0x31EA200
/usr/tmp/output/0000031EA200-0.zip: 204174 bytes

「ZIPファイルらしきもの」を見つけたよ!とか、

Found msoffice at 0x3290000
./output/000003290000-0.doc: 63488 bytes

「Microsoft Wordの文書ファイルらしきもの」を見つけたよ!とかいうかんじです。



見つかったファイルは、-dオプションで指定されたディレクトリに、どんどんと書き込まれていきますが、前述のように、ファイル名は元の名前ではなく、英数字の名前になってしまいます。



# ls *zip
0000031EA200-0.zip      000012D5377C-0.zip      000018C82264-0.zip
(以下略)



# ls *xls
000003243C00-0.xls      00000F67C200-0.xls      000013D04E00-0.xls
(以下略)



# ls *ppt
0000031D2000-0.ppt      000009ACF000-0.ppt      0000109A5000-0.ppt
(以下略)



# ls *doc
0000031CB800-0.doc      00000ADBA000-0.doc      000015F9FC00-0.doc
(以下略)



とりあえず、復旧できたこれらのファイルを、Windowsで開いてみるか・・・としたいところですが、

ちょっと待った!!

これらのファイル、もしかすると、ウイルスに感染したファイルかもしれませんよ。



むやみやたらにファイルを開いてはいけない、というのが昨今のルールですので、開く前には、せめて、ウイルスチェックくらい実行するべきでしょう。念には念を入れて、開くときには、重要なデータが入っていない・壊れてもいいパソコンで、ネットワークから切り離してやる、くらいの慎重さがあってもいいかもしれません。





■ さいごに



というわけで、magicrescueでデータを取り出すことはできるんですが・・・たぶん、がっかりするかもしれません。

うわーん、何千、何万もファイルがあって、どれが重要ファイルなのか、わけわかんないよー

というオチに・・・



まあ、データの内容で検索できるようなファイルだったら、なんとかなるかもしれませんけど。



というわけで、いつもの教訓。

バックアップは重要。まじで。

■ 過去の関連記事









0 件のコメント:

コメントを投稿