先日、外付けドライブにアクセスしたところ、「ファイルまたはディレクトリが壊れているため、読み取ることができません。」と表示され、保存していた全てのファイルが突然見えなくなりました。ファイルシステム異常を疑いつつ、ディスク故障の可能性も考慮して復旧を試みました。想像以上に手間取ったため、手順をまとめておきます。
発生した症状
環境
外付けドライブ（USB接続）
異常発生前の操作
- 外付けドライブをPCに接続
- ファイルを保存
- 外付けドライブを取り外して、別PCに接続
- 2.で保存したファイルが表示されない(←?)
- 外付けドライブを取り外して、元のPCに再接続
なお、外付けドライブの取り外しは、毎回タスクトレイの「安全な取り外し」を実行していました(つもり)。
症状詳細
- エクスプローラでドライブを開こうとすると「ファイルまたはディレクトリが壊れているため、読み取ることができません。」と表示される。
- ドライブ内のファイル／フォルダが一切表示されない。
- 「ディスクの管理」で確認したところ、対象ドライブのファイルシステムは NTFS ではなく RAW と認識されていた。
復旧手順
復旧は、以下の手順で実施しました。
ディスク自体に異常がある可能性も考慮し、まずは保全目的でクローンを作成したうえで、パーティション・ファイルシステムの修復を試みています。
ddrescueでクローンを作成
まず、元ディスクの保全を優先するため、ddrescue を用いてセクタ単位のクローンを作成しました。
ddrescue は、読み取りエラーのあるディスクのクローニングに強く、データ復旧用途で定評のあるツールです。具体的な使用手順については、別記事にまとめたいと思います。
以降の手順は、クローンしたディスクで作業するものとします。
TestDiskでパーティション確認・修復
次に、TestDisk というツールを使用します。
TestDisk は、失われたパーティションの復元や、破損したパーティションテーブルの修復などを行える、オープンソースのデータ復旧ツールです。公式ページから入手できます。
TestDiskの起動
ダウンロードしたファイルを解凍後、フォルダ内の testdisk_win.exe を実行します。ターミナルから起動するか、または、ダブルクリックで起動します。
起動すると、以下の画面が表示されます。
初めに「Create」を選択して Enter を押します。
対象ディスクの選択
次に、復旧対象のディスクを選択します。
「ディスクの管理」で表示されるディスク番号は、TestDiskの \\.\PhysicalDriveX と基本的に対応しています。例えば「ディスク1」の場合は \\.\PhysicalDrive1 です。
ただし念のため、ディスク容量やモデル名なども確認し、対象ディスクに間違いがないことを確認します。
確認できたら、「Proceed」を選択して Enter を押します。
パーティションの種類の選択
次に、パーティションテーブルの種類を選択します。
GPT形式の場合は 「EFI GPT」、MBR形式の場合は 「Intel」 を選択します。
一般的に、最近の大容量ディスクはGPT形式、SDカードやUSBメモリなどの小容量メディアはMBR形式になっていることが多いです。
選択したら Enter を押します。
Analyze / Quick Search
次に 「Analyse」 を選択して Enter を押します。
TestDiskが認識しているパーティション情報が表示されます。
今回はこの時点で 「MS Data」 のパーティションが表示されていました。
MS Data は、Windowsで使用される一般的なデータパーティション（NTFS など）を表しています。
念のため 「Quick Search」 も実行します。
「Quick Search」はディスクをスキャンし、失われたパーティション情報を検索する機能です。
「Quick Search」を実行した結果、改めて 「MS Data」 のパーティションが検出されました。
この画面でパーティション情報の編集などが可能です。
- ← → : パーティション状態の変更（Primary:有効 / Deleted:削除）
- A : 新しいパーティションを追加
- L : バックアップされた情報から復元
- T : パーティションタイプを変更
- P : ファイル一覧を表示
今回のケースでは、パーティション情報やファイル一覧は問題なく表示されました。
確認できたら、Enter を押して次に進みます。
パーティションテーブルの書き込み
次に、TestDiskで確認したパーティション構造を、ディスクのパーティションテーブルに書き戻します。
「Write」を選択して Enter を押します。
「Write partition table, confirm ? (Y/N)」
と確認メッセージが表示されるので、問題がなければ Y を入力します。
書き込みが完了すると
「You will have to reboot for the change to take effect.」
というメッセージが表示されるので、Windows を再起動します。
再起動後、外付けドライブのファイルに正常にアクセスできるようになれば、これで復旧は完了です。
しかし今回のケースでは、再起動後もドライブの状態は変わりませんでした。
そこで、次項では TestDisk の Advanced機能を試します。
Advanced機能
TestDisk の Advanced では、NTFS のブートセクタや MFT など、ファイルシステムの一部の構造を確認・修復できます。
先ほど「Analyze」を選択した画面に戻り、「Advanced」を選択して Enter を押します。
次に、パーティション先頭にある NTFS のブートセクタを確認・修復するため、「Boot」を選択して Enter を押します。
Boot 画面では、NTFS のブートセクタとバックアップブートセクタの状態が表示されます。
もしブートセクタが破損していてバックアップが正常な場合は、「Backup BS」を実行してブートセクタを復元できます。両方破損している場合は、「Rebuild BS」で再構築を試みます。
今回は ブートセクタとバックアップブートセクタの両方が正常で、一致していました。
そのため、この画面での修復は不要でした。
更に「Repair MFT」という機能もあり、NTFS の MFT（Master File Table）をチェックして修復することができます。
念のため実行してみましたが、今回のケースでは特に修復の必要はありませんでした。
ここまで、TestDisk でパーティションの復元やブートセクタ・MFT の確認を行いましたが、特に問題は見つかりませんでした。それでも依然として外付けドライブのファイルにアクセスできないため、次に chkdsk によるファイルシステム修復を試します。
chkdskでファイルシステム修復
TestDiskでパーティションに問題がなかったため、原因はファイルシステム側にある可能性が高そうです。少し遠回りしましたが、最後に Windows 標準ツール chkdsk を使用して修復を試みます。
管理者権限のコマンドプロンプトで次を実行します。
chkdsk X: /fX は対象のドライブです。
/f オプションは ファイルシステムのエラー修復の意味です。
実行結果は以下の通りです。
> chkdsk F: /f
ファイル システムの種類は NTFS です。
ボリューム ラベルは ●● です。
ステージ 1: 基本のファイル システム構造を検査しています ...
23552 個のファイル レコードが処理されました。
ファイルの検査を完了しました。
フェーズの継続時間 (ファイル レコードの検査): 551.80 ミリ秒。
0 個の大きなファイル レコードが処理されました。
フェーズの継続時間 (孤立ファイル レコードの回復): 1.23 ミリ秒。
0 個の問題のあるファイル レコードが処理されました。
フェーズの継続時間 (不良ファイル レコードの検査): 1.16 ミリ秒。
ステージ 2: ファイル名リンケージを検査しています ...
21668 個の再解析レコードが処理されました。
23880 個のインデックス エントリが処理されました。
インデックスの検査を完了しました。
フェーズの継続時間 (インデックスの検査): 1.73 秒。
CHKDSK は、元のディレクトリに再接続させるために、インデックスのないファイルをスキャンしています。
1 個のインデックスなしファイルがスキャンされました。
孤立したファイル 〇〇〇〇 (5B08) をディレクトリ ファイル 5AAF に回復します。
1 個のインデックスのないファイルが元のディレクトリに回復されました。
フェーズの継続時間 (孤立した再接続): 6.94 ミリ秒。
0 個のインデックスのないファイルが lost and found に回復されました。
フェーズの継続時間 (孤立を lost and found に回復): 2.77 ミリ秒。
21668 個の再解析レコードが処理されました。
フェーズの継続時間 (再解析ポイントとオブジェクト ID の検査): 221.02 ミリ秒。
ステージ 3: セキュリティ記述子を検査しています ...
セキュリティ ファイル レコード セグメントを修復しています。
ファイル 9 のインデックス $SII から ID 116 のインデックス エントリを削除しています。
ファイル 9 のインデックス $SDH から ID 116 のインデックス エントリを削除しています。
未定義のセキュリティ ID 116 に対する既定のセキュリティ記述子を作成しています。
ファイル 9 のインデックス $SII から使用されていない 1 インデックス エントリを消去しています。
ファイル 9 のインデックス $SDH から使用されていない 1 インデックス エントリを消去しています。
1 未使用のセキュリティ記述子を消去しています。
セキュリティ記述子の検査を完了しました。
フェーズの継続時間 (セキュリティ記述子の検査): 23.25 ミリ秒。
164 個のデータ ファイルが処理されました。
フェーズの継続時間 (データ属性の検査): 0.87 ミリ秒。
Windows でファイル システムが修正されました。
これ以上の操作は必要ありません。
488369151 KB : 全ディスク領域
301573240 KB : 23134 個のファイル
11336 KB : 166 個のインデックス
0 KB : 不良セクター
104403 KB : システムで使用中
65536 KB : ログ ファイルが使用
186680172 KB : 使用可能領域
4096 バイト : アロケーション ユニット サイズ
122092287 個 : 全アロケーション ユニット
46670043 個 : 利用可能アロケーション ユニット
合計継続時間: 2.55 秒 (2556 ミリ秒)。chkdsk 実行後にドライブが RAW → NTFSに復旧し、エクスプローラーから通常通りファイルが見える状態になりました！
「孤立したファイル 〇〇〇〇」が、まさに最後に書き込んだファイル(フォルダ)の名前に一致しています。そのフォルダの情報が「孤立状態」になっていたようです。
chkdskはその不整合を修復し、フォルダを元の場所に再接続することでファイルシステムを正常化したと考えられます。
「安全な取り外し」を実行したつもりでも、バックグラウンド処理や書き込みキャッシュの影響で完全に処理が終わっていなかったのかもしれません。結果、NTFSの管理情報に矛盾が生じ、Windowsがファイルシステムを正常に認識できずRAW表示になったのかもしれません。
まとめ
今回、外付けドライブに保存していたすべてのファイルにアクセスできなくなり、復旧を試みました。
まず安全のために ddrescue でディスクのクローンを作成し、TestDisk でパーティションの確認・修復を行いましたが復旧しませんでした。最後に chkdsk を実行したところ、ファイルシステムの不整合が修復され、ドライブは NTFS として正常に認識されるようになりました。
おそらくファイルを書き込んだ直後にドライブを取り外した影響で、管理情報が壊れてしまったようです。わずかな不整合でも、すべてのファイルにアクセスできなくなる可能性があるのは少し怖いところです。今回は無事復旧できましたが、同じ症状でも必ず直るとは限らないため、日頃からバックアップを取っておくことが大事だと感じました。
最後までお読みいただきありがとうございました。
