症状/障害判定

特定のフォルダー以下のファイルを開けない。開こうとすると「このファイルは壊れています」という旨のメッセージが表示される。

論理障害と判定。

作業期間

2週間程度

復旧結果

対象となったフォルダーのデータ600MB（3000ファイル）程度復旧

作業内容

前回の続きです。

ファイルシステムFATにおいて、鎖の長さからファイルのサイズを逆算し、その値になるようDirectory Entryのサイズ情報を更新したい！！そうすればより良い状態で復旧できる！！ということだったのですが、それを実現するツールは無さそうなので、自分で作りました。

やることはシンプルなのでそんなに難しいプログラムではないのですが、いかんせん、Directry Entryを追ってファイルのツリー構造を維持したり、FAT内の鎖を正確に追跡していくことまで含めてプログラミングをするのは大変です。

そこで今回使用させて頂いたのはこちらのオープンソースのライブラリ。（このプログラミング言語での言い方だとクレート）

https://github.com/rafalh/rust-fatfs

https://docs.rs/fatfs/latest/fatfs/

ドキュメントを見てみるとファイルシステムFATを扱うにはうってつけの感じです。

また、stableバージョンのソースコードを見てみても、まさにやりたいことが出来そうな感じの関数がありました。

（https://github.com/rafalh/rust-fatfs/blob/stable-0.3/src/fs.rs）

(https://github.com/rafalh/rust-fatfs/blob/stable-0.3/src/table.rs)

上図の部分は、鎖を次から次へと追跡するコードの一部です。

（ClusterIterator構造体にIteratorトレイトが実装されているので、この構造体のインスタンスを作成しcount()メソッドをコールするだけでClusterの数（=本記事でいうところの鎖の長さ）を数えてくれます。）

使いたい部分がライブラリ内でのみ使用できるプライベートなものとなっていたので、これらをパブリックに書き換えます。

データ復旧で行うような処理はデータ破損の危険があることから、通常利用は想定されていないのでしょう。

また、FAT1を利用するようになっていたため、これをこちらで指定できるように改変しました。

通常であればFAT2はFAT1のコピーとなっており、同じ内容であるから指定する意味はありませんが、本案件ではFAT1は破損しているので、正常なFAT2を指定できるようにしたかったからです。

（とはいえ、本案件ではFAT1をFAT2で上書きする工程を挟むのであまり意味はありません。今後似たようなケースに遭遇したときに、使用するFATを指定できた方が良いのではないかと思い、ほんの少しの修正を加えました。上記ライブラリのコードを読んで恥ずかしながら初めて知ったのですが、多くのケースではFATはMirroringされていますが、ActiveなFATを指定することもできるようです。上記ライブラリではActiveなFATがあればそれを利用、ミラーリングされている場合は最初のFATを利用するようになっていました。BPBにFATはMirroringかActiveかのどちらか、ActiveならどのFATかを示すフラグが存在するのですが、当該部分を変更できるようにすれば、本案件でも破損したFAT1を正常なFAT2で上書きする必要もなかったかもしれません。）

FATの鎖の長さは上記ライブラリを使って求めることができるので、プログラムのメインの部分では鎖の長さに基づいてファイルサイズが適正かどうか判定するロジックを実装しました。

各ファイルに対して、

① Directory Entry上のサイズが鎖の長さから1を引いて逆算したサイズより小さい => Directory Entry上のサイズが無効なのでこれをFATの鎖から逆算した値に修正

② Directory Entry上のサイズが鎖の長さから1を引いて逆算したサイズと、鎖の長さから逆算したサイズの間にある => 正しいサイズと判定しそのままにする

③ Directory Entry上のサイズが鎖の長さから逆算したサイズより大きい => FATの鎖が不正かもしれないし、Directory Entryのサイズ情報が不正かもしれないので、修正不可と判定して何もしない

というようしました。

プログラミングは本業ではないので、ソースコードを追ったり改変したりするのは簡単ではありませんでしたが、それでも最初から作るよりは随分時間の節約になりました。（メインの部分のロジックは非常にシンプルで簡単にコーディングできたので、大半の時間はライブラリのソースコードを読んで利用できそうなところを探していた気がします。）

こうして自作したプログラムを走らせて、Directory Entryのサイズ情報をFATの鎖の長さに基づいて修正したところ、確認した限りでは全てのファイルを復旧することができました。

ファイル名があり、かつ、フォルダー構造を維持した状態での復旧です。

障害前とほぼ同じような使用感です。

カービング（=ファイルに特徴的なデータに基づいて復旧する手法、ファイル名やフォルダ構造は喪失する）で復旧したときよりも、はるかに良い状態です。

FATの鎖の長さから逆算した値であって正確なファイルサイズではないため、完全に元通りという訳ではありません。

例えば、Excelのファイルを開くと、相変わらず「一部の内容に問題が見つかりました。可能な限り回復しますか？」というポップアップが表示されます。

しかし、そのポップアップさえ除けばデータは元通りで、きちんと表示されます。

今回は考えうるベストな復旧ができたのではないかと思います。

プログラミングができ、ツールを自作できるデータ復旧エンジニアはそう多くないらしいです。

しかし、スクラッチラボでは論理障害に対する復旧ツールの作成も可能です。

多くのデータ復旧会社が使用しているツールであっても復旧できない論理障害にも対応できる可能性がひょっとしたらあるかもしれません。

お困りの際はぜひスクラッチラボにご相談ください。