データ復旧技術に関する勉強会 [ハードウェア方面＆ソフトウェア方面]

A, クリーンルーム作業 [ハードウェア方面]

データ復旧サービスでは、「クリーンルーム作業＝高い技術力」という図式が一人歩きしております。
この認識は大変な誤りです。クリーンルーム作業はあくまでも作業の一部分に過ぎません。
総合的な症状判断力と、データをスキャン＆再構築するソフトウェアの性能が復旧率を決めます。

しかしながら、おろそかにしてよい訳ではございません。
クリーンルーム以外で開封いたしますと、どんなに優れたソフトウェアでも、制御不能となります。
※ もちろん、100％制御不能ではございませんが、
業者に出されるからには、100％ベストを尽くす作業が必要と思います。またやり直しは絶対に不可能ですので、
弊社でもこのようなご案件は申し訳ないのですがお断りとさせて頂いております。

このあたりのバランスが明確にされていない(されようとしない)ため、色々厄介な問題へと繋がっております。

ヘッドアンロードはヘッド先端がランプと呼ばれる部品に格納される形で収められます。
CSS方式はヘッド先端がプラッタ内週部に接触する形で収められます。
※ いずれにせよ、回転にて生じる空気の流れを利用して浮遊しております。
それだけ精密な機械となりますので、正確な作業を要求されますが、
その手順は毎年改良され、問題なくヘッドアンロード, CSS方式の両方を復旧することが可能です。

回転にて生じる空気の流れを利用して微小な「ディスク-ヘッド間隔」を作り出しておりますので、
各部品を固定するネジなどが重要な要素となります。ネジの締め具合に関しましては、それを測定できる装置を利用いたします。
また、ヘッド交換作業に関しましても、専用器具(※1)により容易かつ確実に行うことが可能となりました。
※1：磁気ヘッドを格納するスライダ(これが浮遊します)の姿勢を壊さずに、
ランプからの取り外し、およびランプへのセットを行う専用器具となります。
CSS方式では、ヘッド先端がディスク内周部に存在するため、器具というよりは「ヘッド交換装置」になっております。
4プラッタまで対応、数秒でヘッドの出し入れをできるもので、こちらも確実です。
※ 意外とCSS方式のヘッド交換には対応できていない業者もございますので、必ず確認を必要とします。
以下、ヘッドアンロードとCSS方式の画像を置いておきます。ご参考になれば幸いです。
左側がヘッドアンロード、中央がCSS方式です。ヘッドの格納位置にご着目ください。左側はヘッド先端です。

モータが焼けてしまい、動作不能となる例です。このような場合は、モータを交換するのではなく、プラッタを正常モータへ移植します。
モータはハードディスクと一体を成しまして、これを外す前に、プラッタを外す必要があるためです。
すなわち、プラッタを外した段階で他のモータへ移植した方が、手順が少なくて済むという流れです。

こちらは・・手作業ではまず無理です。
プラッタを固定するネジの精度が非常に高く、この部分は機械の出番です。
技術パートナー様と話し合いのうえ完成いたしました「専用装置」を利用いたしております。

B, スキャン系 [ソフトウェア方面]

現在、メインで改良が進められているのはソフトウェア方面の技術です。
復旧速度と復旧精度を追求し、速やかで確実なデータ復旧を目指しております。

[課題1・・復旧速度の改善]：シングルスレッドとマルチスレッド

2005年の頃に登場いたしました「デュアルコア」を発端に、
2010年にはクアッドコアのパソコンに手が届くようになりました。性能を決めるとされるクロック数(※注1)が中々伸びないため、
コアの数で性能向上を図る路線に変更となったようです。ところで、このような変化は「一つの仕事を、高速に処理するタイプ」から、
「複数の仕事を、速度を落とさずに並列処理する方面」への転換を示します。
※注1：本来、クロック数だけでは性能は定まりません。1クロックあたりの性能も重要で、確認が必要です。

そのため、よく伺う話が「スレッドの数」および「スレッドの優先順位」です。
一つのスレッドで全処理を行う内容をシングルスレッド、反対に複数のスレッドを利用する場合はマルチスレッドと呼ばれております。
シングルスレッドの場合は「順番通り」に処理されます。
しかし、他のコアの手が空いている場合、それらを同時に利用し、合計処理時間を短縮したい所です。

ただ、上手く実装しないと1スレッドあたりの処理時間が延びてしまいます。また、同期も必要です。
そのため、弊社では処理内容別に細かく分けて、色々と「組み合わせ」を行う内容になっております。

[課題2・・復旧精度の改善]：不良セクタの間隔・規則性・精度と時間のトレードオフ

不良セクタの拡散(読み書き不能セクタの拡散)に関しましては、
HDD容量が100GBを超えたあたりから頻繁に拝見するケースとなりました。

規則性に関しましては色々な手法で解決いたしておりますが、不良セクタの間隔に関しましては、まだまだ詰めていこうと考えております。

上が旧技術、下が新技術(見込み)です。ただ、まだ改良中のため現在のシステムは上と下の中間点です。
それでも、ようやく形になってきまして、
この地点までの成果は「不良セクタシミュレーション」にて公開させていただきました。
※ 中間点の技術ですが、それでも500GB〜2.0TBのプラッタ傷などには大きな威力を発揮いたします。

スキャン結果を詳細に解析し、全てメモリに収めて後から拝見する形式を検討中です。

また、スキャン中にスキャン結果をリアルタイムに次々と代入し、現在の状態を遷移させる方式も検討中です。
※ 遷移させ、危険と判断できた場合はそのセクタの内容をメモリに収めます。
次回、読み込めるか分かりませんので・・(^^;。
今現在(6/8)も試行中で、実験ではメモリが1GB程度予約できれば、数パーセントの復旧率向上が見込めそうです。
また、セクタ番号(LBA)は絶対に重ならないため、木構造が有用とみております。(こちらも色々と試しています)
※ 故障予測には前者(後から解析)、データ復旧には後者(遷移図)が役に立つとみております。

物理障害のデータ復旧に関しましては、
特に大きく構造が変わらない限り、現状で問題ないと判断いたしております。
ただ、イレギュラーなケース(指紋付き)は別に改善する必要があると考えておりまして、
空いた時間を活用いたします。※ 指紋付着に関しまして扱う量が増加しております。
[お願い]：無意味にハードディスクの蓋を開ける事だけは避けてください。

メモリ管理を導入いたしました。
これは復旧精度に直接繋がる訳ではないのですが、不意なエラーなどが全て把握できるため便利になりました。
また、公開版のFromHDDtoSSDにも導入いたしまして、「動作安定」を追及いたしております。
※ Ver2.0以降に全て搭載されます。なにとぞよろしくお願いいたします。

約2ヶ月ぶりとなりましたが、夏場の忙しい中、お集まりいただきありがとうございます。
SSDおよび仮想化環境に関する考察を行いました。

普及に伴い、ご依頼いただく機会が増加傾向にあるSSDに関する内容を取り扱います。
色々な面でHDDと異なりますので、スキャン周りに関しましては、
SSD専用のタイプを新たに構築し、テストを重ねて導入する必要性が強いことをまとめました。
なお、データ再構築方面に関しましては、ソフトウェアの上位分野(ユーザモード)となりますので、
ハードウェアの違いによるプログラム変更の必要性はありません。
やはり、構造が変わりますと、問題となるのはハードウェアを司るカーネル方面です。

余談ですが、Windowsの旧版(2000,XP)はHDD[ハードディスク]に最適化されておりますので、
SSDのパフォーマンスを最大限に引き出すのには無理がございます。
しかしながら、この頃はHDDしかない時代ゆえ、この問題に関しましては致し方ない話です。

まず、正常なSSDに対しまして、そのアクセスの変動を全て記録してみました。
189MB/s〜241MB/sの間を行き来しておりまして、連続したアクセスでも、このような常時変動を吸収できるものが必要のようです。
HDDと同じ状態遷移では、おそらく異常判断が多く発行され、スキャンがまともに通らなくなります。
※ 使用ソフトウェア：FromHDDtoSSD Ver2.02 完全スキャン内「詳細ビュー」軌跡表示有効で測定しました。

参考：約 32,000時間使い込みましたウエスタンデジタル製 ハードディスクです。
少々不安面がありますが、まだ30,000時間は問題ない感じがいたします。(補足：SCSI/SASタイプのHDDです)
※注：右肩下がりな点に関しましては、内周部の速度が低くなる特性ですので、故障ではございません。

着目点は、線の幅(振幅)です。平均的にはそこまでブレていません。
単にスキャンしただけでも、これだけの違いがあるため、故障した際の特性は大きく異なってくる訳です。

次に、仮想化環境に関するデータ復旧の内容です。

時間の都合にて、今回は表面に触れた程度ですが、次回よりより深く考えていきたいと思います。
仮想化環境となりますと、難しそうなイメージがありますが、(広まっておりますが？)
バイナリイメージを仮想マシンにマウントさせ、動作させているに過ぎません。仮想マシン自体がとても難しいのは分かりますが、
バイナリイメージはファイルシステムとオペレーティングシステムが格納されたイメージに過ぎません。

データ復旧では、仮想マシンを追求するわけではなく、
バイナリイメージからデータを復旧するのが目的です。・・長くなりそうなので、次回です。

予定より大幅に遅れておりました「故障予測」方面の報告です。
遅くなりまして、大変申し訳ございません。
従来の技術を大幅に改良した「新型(Ver2.0)」にて、近い内(14日以内)にリリースできます。

故障予測の演算部分には、弊社およびパートナー様の「データ復旧成功事例」を採用し、
実際に壊れ易い部分を予測しながらスキャンを行います。
また、不良セクタシミュレーションを組み込みまして、この先の長期的な劣化にも対応できます。
S.M.A.R.T.のみの予測と比べましても、ベースから動作原理が大きく異なります。

なお、S.M.A.R.T.に関しましては、「利用しない」ではなく、
故障ドライブを個別に調査して得られる「独自のしきい値」にてある程度の改善はいたしております。
しかしながら、S.M.A.R.T.自体の内容が正確ではないドライブも数多く、
そのような場合には、S.M.A.R.T.ではなく、先程のスキャンによる予測しか方法がありません。

本日はソフトウェアを動かして動作状況を伺っただけですが、
次回より内部に関する詳細な内容に入ります。(10月11日)

Ver1.xの故障予測では、S.M.A.R.T.以外に予定しておりました故障予測スキャンA〜Dのうち、
スキャンAのみしか搭載できず、大変申し訳ございません。
Ver2.0Aにて、完成いたしております。
(スキャンA〜スキャンCを実装済：残るスキャンDはデバイスドライバが必要となるめ、もう少しかかります)

調整の方に関しましても、ほとんど完成の域に近づいたとみております。
その他、報告を受け賜っておりましたバグを修正し、Ver2.0Aをリリースいたします。

度々、リリース延期が繰り返されてしまい、大変申し訳ございません。
また、Ver1.3Aの方もバグが存在したため、修正いたしましてVer1.3Bをリリースいたします。

※ アクティブレストレーション [拡大参考：ストレージスコアグラフの内部に動作状況がございます]

[拡大画像]

故障予測スキャンを利用して不良箇所を修復する機能を搭載いたしました。(アクティブレストレーション)
これにより、軽微な不良セクタは速やかに置き換えられ、
S.M.A.R.T.[05]のカウンタが減少して収まる流れとなりました。

原則的に、不良セクタが発生した場合は速やかに交換するのがお勧めとなりますが、
状況によってはそうもいかない事が分かりまして、本機能の搭載に至っております。
例として、遠隔地にご導入いただいた場合です。この場合、すぐに交換する事はできません。
それならば、修復を試みて故障時期を伸ばした方が得策と考えました。

また、実験ではHGST製,Seagate製にて動作を確認いたしております。(15台以上)
その他のメーカさんに関しましても、現在、調査を行っております。
※ HGST製：読み込み不能セクタ2箇所＝＞本機能で修復＝＞6ヵ月経過しましたが問題なしです。
※ Seagate製：読み書き不能セクタ＝＞本機能で修復＝＞3ヶ月で故障に至りましたが、先延ばしに成功です。

※ 破損したファイルシステム(FAT,NTFSやHFS等)を独自の技術で探索いたします。
※ スキャン系統のオブジェクトがセクタレベルの異常を検知すると、
その部分をメモリに取り込んでデータを保護するプロテクト機構を搭載しております。
また、細かくメモリを多用するため、全てWindows任せではなく、独自に「厳重な管理」を実装しております。
可変長ケース・固定長ケースを厳密に決めまして、別々に最適なアルゴリズムを実装し、管理しております。
(Windows任せでも大丈夫そうなのですが、意外なところでメモリ確保失敗というケースを拝見しております。
通常、確保失敗の場合は例外処理でソフトウェアを落とすか、やり直せば良いのですが、
データ復旧は「チャンスが1回」の世界なので、そうはいきません。大変シビアですが、チャンスを生かします)

最適なメモリ管理も決定いたしまして、弊社では業務用のDIRECTSCAN Ver2.0+および、
データ復旧ツール機能として搭載させていただくFromHDDtoSSD リカバリエディションを進めております。
※ 2011年1月1日にDIRECTSCAN Ver2.0+が完成いたしまして、早速ですが1月4日以降はこちらに切り替えております。
1バイトでも多くのデータを復旧できるように尽力いたします。よろしくお願いいたします。

弊社にとって、残る課題は「ユーザインターフェイス」です。
DIRECTSCAN Ver2.0+の場合は弊社および技術パートナー様のみご利用となりますので、
多少、見方・操作に関して至らない部分がありましても、・・・ですが、(^^;
FromHDDtoSSD リカバリエディションは一般公開となりますので、
迷わず操作でき、操作が直感的で簡単ゆえ、復旧率も確保する必要性がございます。
ウィザード形式で簡単に・・といきたい所なのですが、相手が壊れているだけに、
詳細な設定を試行錯誤で決定し、スキャンを開始するケースなどもありまして、色々と調整中です。

1月23日の予定が2月20日までずれ込んでしまい、大変申し訳ございません。
メモリ管理システムの完成に、1ヶ月ほど遅れてしまったのが原因となります。(申し訳ないです...)

[まず・・データ復旧向けメモリ管理に関しまして]
2月中旬に、ほぼ完成いたしました(^^;
基本的な構造はテーブル＆インデックスとツリーを組み合わせた構造となっておりますが、
データ復旧プロセスにおける、いわゆる「癖・特性」を大いに含めた形となっております。
そのため、データ復旧用途ではキビキビ動作いたしますが、
他用途ではもっさりする可能性も大いに存在することになります。(といっても、数百万重なった場合ですが...)
ただ、目的(データ復旧向けメモリ管理)は満たしておりますので問題ありません。
※ 内部の一部処理にアトミック性を必要としますが、マルチスレッド・マルチコアでも余裕にOKです。
なお、コストの大きい例外処理は一切ありません。(このあたりは徹底的に検査し、余計な物は省きました)

これにて、複雑に壊れた数百万レベルのファイルサーバ(NAS)などの復旧時間を短縮する事ができます。
弊社も、これを正式導入次第、ファイルサーバ(NAS)復旧をより強化する所存です(^^;

実際に現場で利用するDIRECTSCANに組み込むのは3月中旬となります。(問題ない場合)
※ なお、リリース予定の次期FromHDDtoSSDには、既に本メモリ管理を「組込済み」です。
現在も検査を行っておりますので、このまま問題ないと判断でき次第、リリースいたします。
なお、FromHDDtoSSDには復旧以外の機能も多く含まれておりますが、もっさりの心配はご不要です。
復旧以外にて実施される数百・数千レベルの確保程度では、体感速度の違いは全く出ません。

壊れかけのHDDを安定させてスキャンする「ヘッドレストレーション」機能のリリースが近づいております。
自動制御への第一歩になりつつ、手ごたえも感じております。
※ 完全にコンピュータ側で制御できれば、莫大なスキャン時間から解放される事になります。(コスト削減)

DIRECTSCANでも厳しい場合、次の手といたしまして「ヘッドレストレーション」を使います。
なお、上のスクリーンショットは自動制御のみの「公開」バージョン(＞＞ FromHDDtoSSD Ver2.0Cへ搭載)です。
データ復旧業務では手動による制御変更(コマンド)をサポートした専用バージョンを開発・採用しております。
これでも厳しい場合は「クリーンルーム作業」にて修理を必要とするレベルと判断いたしております。
※ 初期診断作業に関しまして重要な点が、ここに存在いたします。
僅かな差でも、処置方法が大きく異なるためです。(このようなミスは、後々大きくなって厳しい状態となります)