TestDiskで瀕死の外付けHDDからデータを救出

一年半ぶり二回目のサルベージ。


  • 2017/10/01 作成

Contents


概略

2016年1月、320GB(298GiB)の外付けHDDが瀕死の状態になり、TestDiskを用いて全データのサルベージを行い、見事に成功した。

そして2017年9月、今度は、かなり前から使っていた2TBの外付けHDDが瀕死の状態になった。症状が異なったので色々試したが、最終的にはTestDiskを使うことになった。

なお、この記事は基本的にWindows使用者向けである。各種環境は以下。

  • OS: Windows 10 Home、64ビット
  • 当該HDD: HD-LBU3 (BUFFALO USB3.0 外付け 2TB HD-LB2.0TU3/N)
    • Yドライブ (通常稼働時にドライブレターの重複を避ける意図でYを明示的に割り当ててある)
    • 2013年3月の購入時点からしばらくは断続的に稼働、その後は2017年9月に問題が生じるまでほぼ連続稼働
    • 寿命が4.5年というのは短いように感じられるかもしれないが、熱や振動に曝される状況下でかなり雑に扱っていたので妥当な寿命という感じ

「データ エラー (巡回冗長検査 (CRC) エラー) です。」

不具合は突然現れた。当該HDD上の某exeを起動させようとダブルクリックしたところ、いつまでたってもウィンドウが現れない。タスクマネージャーを覗くと起動自体はできているようである。原因がわからず何度もexeを再起動してみると、5回目くらいで何とか起動してくれたが、プログラムの設定やログ(外部ファイルとして保存されている)が正常に読み込めなかった。どうやら一部のファイルが正常に読み込めないらしい。

そこで、エクスプローラで該当HDDの中身を確認する。現状では、「PC」欄の容量のバーみたいなやつも正常に表示できている。ルートディレクトリも正常に表示できる。しかし、何階層か深いところへ移動しようとすると、「データ エラー (巡回冗長検査 (CRC) エラー) です。」と言われてしまった。

このHDDは瀕死状態だ。さっさとデータを救出したい。しかし2016年1月の一件よりは症状が軽いので、もっと簡単にデータを救出できそうな気がしないでもない。

CrystalDiskInfo: この時点でのHDDの状態

この時点で瀕死HDDの状態は下の画像のような感じ。いかにも不健康という様子。

CrystalDiskInfoの表示
CrystalDiskInfoの表示

chkdsk: ダメ絶対

有名な話ではあるが、データをサルベージしたいならチェックディスクは絶対にダメ。症状が悪化するかもしれないし、サルベージできたはずのデータを殺すようなものだ。

FastCopy: 同期OK・移動NG

いくつかのサイトでは、FastCopyを使ったサルベージ方法が紹介されている。といっても、FastCopyを用いて健康なHDDにデータをコピーするというだけだ。SourceとDestDirを指定し、動作モードに「同期(サイズ・日付)」を指定すればよい。

さて、この方法でファイルをコピーすると、一部のファイルはCRCエラーでスキップされてしまう。99%くらいのファイルはコピーできるが、エラー部分はどうにもならない。結果として一部のファイルは取りこぼしてしまうことになる。そこで、こんな余分なことを考えてしまった。「同期ではなく移動にすれば、取りこぼしとそれ以外の区別が分かりやすなるのでは?」

という経緯で、FastCopyにより移動を行ったところ、途中で突然USBデバイスが全て接続解除され、他のデバイスは勝手に再接続してくれたが、該当HDDだけは上手く再接続できなくなってしまった。

どうやら、このファイル移動で余計な負荷がかかったらしく、この時点でエクスプローラからルートディレクトリすら表示できなくなってしまった。瀕死のHDD上のファイルに直接何らかの操作を行うのは絶対にNG。ファイルの移動は瀕死のHDDから見ればファイルの削除という操作を含んでいるのでNG。

TestDisk: 大本命

トラブルが続き、結局は2016年1月と似た状況になってしまった。そこでTestDiskの登場である。本来TestDiskは「間違えてパーティション削除しちゃったよ~」というときに使うツールであり、データサルベージ用のツールではない。しかし、この状態のHDDからのサルベージができるツールはTestDisk以外には知らないので、有り難く使わせてもらった。

起動方法

TestDiskを起動する方法には主に2種類ある。

  • exeを直接起動する
  • Ultimate Boot CD (UBCD) というLinuxライブCDから起動する

どちらを使ってもよいが、ライブCDを用意するのは面倒なのでexeを直接起動することにする。まずは普通に64bit版の「testdisk_win.exe」を使う。

ターミナルから使うのかと思いきや、ダブルクリックで起動するのが正しいやり方らしい。

起動すると初めに、ログを作成するか訊かれる。初回ならCreate、2回目以降ならAppendを選択するのが賢明。ログがないと後で様子を確認できないし不便。

永遠に「Please wait...」

ログを作成するかどうか決めた後、本来であればすぐにHDD一覧が表示される。しかし、何らかの問題があるHDDが1つ以上接続された状態だと「Please wait...」と表示されたまま永遠に待たされることがある。

Please wait... から一向に進まない状態
Please wait... から一向に進まない状態

この状態からなかなか抜けられなかったので、いろいろ試した。

TestDiskを何度も再起動→効果なし

ログの扱いを決めると、「Please wait...」と表示されてディスク検索が始まります。問題がない場合はすぐに次の画面に進みます。

今回のHDDはここから先に進めません。いくら待っても進まないので、「No Log」>「十秒弱待つ」>「Please wait...のまま」>「右上の×を押して終了」>「TestDiskを起動」>「No Log」、とひたすら繰り返します。10回程度やっても進まない時は、一端HDDを抜き差しし、HDDを認識する音が聞こえてから再び繰り返します。HDDをすぐに抜き差しすると、HDDに負荷がかかるので10秒程度間を置いてから接続します。

上の相性が悪いように見えたLogitech製の変換器では何度やっても進みませんでした。

同じことを試したが効果なし。

64bit版が駄目なら32bit版だ!→効果なし

そんな中、認識を回復させるツールとしてtestdiskというソフトが多くのサイトに取り上げられていたので、さっそくtestdisk公式サイトに行ってWin64ビット版をダウンロード。

実行するも、検索中で画面が止まる。あれ?何度もやり直すがだめ。止まる。β版だからダメなのか?
もう一回公式サイトに行き、Win32ビット版をダウンロード。今度はうまくいったよ。

同じことを試したが効果なし。

なお、不注意なことに、ここから先は32bit版を使い続けてしまった。

「Please wait...」になったらHDDを抜く→効果なし

「Please wait...」で止まっている時に問題のHDDを抜くと先に進みますが、Logitech製では次の画面で該当HDDが一覧に表示されず、元の変換基板では表示されました(されないこともある)。このあたりの表示の有無も相性の判断基準になるかもしれません。

元からの外付けUSBHDDをSATA接続のものと比べるのはアレかもしれないが、「Please wait...」になったところで問題のHDDのACアダプタをぶっこぬいた。すると…HDDのリストが表示された!

…大丈夫か、コレ?(結果から言うとダメでした↓)

ファイル一覧が表示されない!

HDD一覧以降、(詳しくは後述するが)[Analyze]→[List] でディスク内のファイル一覧が表示されるはず。しかし、このときは「.」「..」の2つしか表示されなかった。つまり、どんなファイルがあるのか実質的に何も分かっていないのと同じ。

Quick Search が短すぎる!

[Analyze]の代わりに[Advanced]→[Quick Search]を選択すると、パーティションの検索を行うことができる。普通は10時間単位で時間を要するのだが、この状態のHDDだと2TBのHDDで十数分程度しか待たされない。この間、画面には「Read error at ~」という表示がものすごい速さで表示されまくる。そして結局何も検出できなかった模様。仕方がないので、と[Deeper Serch]を選択しても同じくらいの時間待たされた挙句、何の成果も得られない。

MBR書き込みができない!

パーティションの情報がいかれたのか?と思い、MBR書き込みを決断。[Analyze]の代わりに[MBR Code]を選択、何度試しても「Write error: Can't write new MBR code.」と言われてこれも成果なし。

HDD選択メニューに戻って何回も試す→効果なし

ダメだった。

PCを再起動して何回も試す→効果なし

ダメだった。

ACアダプタやUSBを何回も抜き差し→やったぜ。

HDDが傷まない程度の頻度で接続を物理的に何回もやり直す。エクスプローラでルートディレクトリが表示できるまで何回も何回も試すと…10回目くらいでルートディレクトリが表示できたので、この隙にTestDiskを起動する。

「Please wait...」が表示されてからしばらく待つと、めでたくHDD一覧が表示された。

HDD一覧

「Please wait...」の壁を超えるとHDD一覧が表示される。

HDD一覧
HDD一覧

CRCエラーが出ているドライブ(Yドライブ)は表示されていないが、ディスクとしては認識されているので、それを選択する。

データのサルベージ

ディスクを選択すると表示されるのがこのメインメニュー。

メインメニュー
メインメニュー

ファイルをサルベージしたい人は[Advanced]を選択。少し待たされてパーティションのリストが表示される。

パーティションのリスト
パーティションのリスト

ここで[List]を選択して少し待つと、該当パーティションのルートディレクトリのファイル一覧が表示される。

ルートディレクトリのファイル一覧
ルートディレクトリのファイル一覧

画面の指示に従い、"a"を押して全ファイル・ディレクトリを選択し、"C"を押す。コピー先を選択してまた"C"を押す。今回は次の通りファイルをコピーした。

  • コピー元: Y:\ 以下の全ディレクトリ・ファイル
  • コピー先: F:\Y2\ 以下に元通りそっくりそのまま

これでファイルのコピーが開始される。普通のドキュメントなら秒間40ファイルくらいのレートでコピーされる。数十時間程度待つとファイルのコピーが終了する。当方の環境では2TBのデータ救出に丸二日を要した。

コピー完了
コピー完了

赤色で「Copy done! 5490449 ok. 4 failed」と表示されているが、全ファイルのコピーが成功したときは緑色の字で表示される。

ログ

99.999927% のファイルはサルベージできたので、おおむね満足している。しかし、TestDiskの画面を見ても救出に失敗した4つのファイルがどれなのかわからない。このファイルたちの重要度はかなり大切だ。気になるのでログを見てみた。

ログをShift-JIS(標準)で開いたところ
ログをShift-JIS(標準)で開いたところ

ログは基本的にShift-JIS(標準)、ファイル名部分のみUTF-8になっている。

ログをUTF-8で開いたところ
ログをUTF-8で開いたところ

塗りつぶしてしまったからわからないかもしれないが、UTF-8で開くと日本語ファイル名もきちんと文字化けせずに表示できる。で、エラーの原因だが、「File name too long」とのこと。

この制限に引っかかる状況は主に2通りに分けられる。

  • パスが長さ上限(1023バイト)を超過している
  • ファイル名が長さ上限(255バイト)を超過している ← 今回はこっちだった
    • UTF-8 で256バイト以上になるファイル名が弾かれる

詳細は以下。

幸いなことに重要度はかなり低いファイルだったので、個別での対応は見送るという手もあったが、せいぜい4つだけなので手動でサルベージした。幸運なことに、特にCRCエラーで引っかかったりはしなかった。

CRCエラーの影響

大事なのは、エクスプローラやFastCopyではCRCエラーでコピーできなかったファイルでもTestDisk経由で救出できるということである。FastCopyでサルベージを行うと、CRCエラーのファイルはスキップされてしまう。

では、CRCエラーでどうにもならないと思っていてどうにか救出できたファイルは、破損していたりしないのだろうか?

まず、FastCopyのログを見て、CRCエラーでスキップされてしまったファイルを確認する。次に、このファイルをTestDiskで救出したものを実際に開いて、何か異常がないか確かめる。

試しに動画を開いてみたが異常は見られなかったので、CRCエラーの影響は(パッと見は)ないようである。

システムファイルが丸見えに

TestDiskでサルベージしたファイルは、更新日時はそのまま維持してくれるが、「$RECYCLE.BIN」みたいなのが丸見えになる。まあ別にいいけどね。

他にも、たとえばネットから落とした「~.txt」みたいなのをサルベージすると、一緒に「~_Zone.Identifier」てのも出てくる。これは ADS (Alternate data streams) という代替データストリーム情報で、元々はファイルとして一緒に置いてあるという訳ではなく notopad から「~.txt:Zone.Identifier」の形で参照できたものだが、サルベージすると実態のあるファイルとしてたくさん出てくる。まあ別にいいけどね。

まとめ

CRCエラーが出ると、HDDは消耗品であるという事実を思い知らされる。RAIDとかコスパ悪スギィ!と思い込んでいたが、リスクを加味すればデータの重要性によってはむしろ低コストなんだなあと改めて気付く。