例えば、Hot spareを設定している場合、障害が発生したHDDとデータ情報が同様の為、容易に特定することが出来ますが、後から破損したものに関しては情報が全く異なる為、考えられる全ての組み合わせでデータの抽出を行い、分析を行う必要があります。破損データの特定は、1台の破損からアクセスエラーになるまでの時間が長い程、タイムスタンプのずれをある程度見当をつけて行うことが出来ます。しかし、期間が短い場合は更新されていない情報が少ない為、破損データの特定には経験のあるエンジニアであっても時間を要する場合があります。
　企業様で使用されるサーバではフォルダの入れ替えなどが頻繁に行われる為、一定の情報が書き換わるだけの「ツリー構成」から破損データを特定することは非常に難易度の高いものとなります。更に、NTFSの管理情報では下層の情報が含まれている為、情報の適合は可能ですが、Linuxの場合では下層フォルダ内にしか情報がないため破損データの特定は難易度が上がります。

　11月に入ってからデータ復旧のお問合せがあったRAID/サーバ機は、HDD計10台で構成され、2台はOS用のRAID1、6台をデータ保存用のRAID5、Hot spareとして2台を設定したサーバ機でした。分析の結果、RAID5を構成する1台のHDDが2か月前にヘッド破損によって停止していたことが分かりました。担当者の方はその状態を知っていながらもRAID5のシステムとHot spareの設定に過信し、運用を続けていました。
　RAID/サーバ機を構築する際、同じ製造年の同メーカーのHDDで設定するため、障害の発生も同時期に起きる可能性が高くなることから、この機器がアクセスエラーでお持込みされた時には計4台のHDDが運用を停止した状態でした。それまで問題なく運用できていただけでなく、OSの保存領域にも問題はなかったことから、アクセス不可になるまで、最初に破損したHDD以外の障害には気づくことが出来なかったようです。
　4台のHDD障害に加えてLinux環境にあった為、破損データの特定と分析は非常に難易度の高いものでしたが、ヘッド破損が発生したHDDの分析と、全てのHDDを組み合わせてデータ抽出を行うことでデータの復旧に成功しています。