ビッグデータの復旧技術応用:パートナー様、多くのユーザ様との開発の軌跡

■ アクセス [ベスト 7]
1:□ ドライブ検査から自動データ復旧まで・・ FromHDDtoSSD Build 2820:最新版ダウンロード
2:データ復旧不能となる最大の要因1:認識可能なドライブを分解され、「*枚目のプラッタに傷がある」と・・?
3:データ復旧不能となる要因2:磁気ヘッドマップ作成およびヘッド切り替えができないため、対応不可?
4:検査はお断り?お客様実例からの、データ復旧サービスの実態について(検査はできないのに・・・復旧はできる?)
5:□ ドライブ故障統計(ビッグデータ):多角的な解析:フリーのストレージ故障予測 [S.M.A.R.T.のみでは厳しい]
6:大容量ドライブに関するデータ復旧の仕組み 機械学習スキャン(AI)による高い復旧率(最後までスキャン可能)
7:担当者ブログ ※ 2017年はAI完全自動ドライブ復旧システムおよび統計スキャンについて、まとめます。

ホームビッグデータの復旧技術応用:パートナー様、多くのユーザ様との開発の軌跡

技術パートナー様向け

いつもお世話になっております。データ復旧技術に関する勉強会についてまとめております。
※ 2010年4月29日より、データ復旧技術&故障予測技術に関しまして実施いたしております。
※ ベータ版の検証にご参加くださり、厚くお礼申し上げます。
※ 2012年10月17日 正式版のリリース(FromHDDtoSSD Ver2.1)に至りました。ありがとうございます。
これでバグを徹底的に取り除き、効率的に復旧件数を伸ばしてコストを削減する方向に進めていきます。
※ 2012年12月下旬~2013年1月上旬にかけて、ようやくコードが統一される見込みとなりました。
( 検証のため、手続き型とオブジェクト指向が混在していたのですが、ようやくオブジェクト指向へ移行できます )
後は空いている機能の穴埋めに全力を注ぎます。
※ ホコリ前提復旧機能、順調に進んでおります。ビッグデータを取り込んで安定制御させます。
※ ドライブリアルタイム解析の同時スキャン(並列スキャン)に成功いたしました。
※ 2014年にビッグデータ解析に着手いたしまして、ある程度の運用ノウハウを蓄積いたしました。
※ 2015年1月より、ビッグデータを活用し、各機能を大幅に強化いたします。なにとぞよろしくお願いいたします。
※ 2015年3月:さらに使い易い形になるように、運用ノウハウを構築中です。
※ 2015年6月:機械学習によるデータ復旧技術の構築を完了いたしました。さらに、「状態変化サイン」を投入いたしました。
※ 2015年9月:自動的にドライブ故障予測(ビッグデータ)を解析する「ドライブマイニング」をサポートいたしました。

※※ 2010年 技術報告 ※※

4月29日~5月3日 (ゴールデンウィーク中) 期間中の内容 ここから・・・

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

クリーンルーム作業C クリーンルーム作業B

以下、弊社および技術パートナー様との共通認識(ハード方面への復旧技術)となっております。
※ 先日は物理障害担当の方とお話させていただきました所、やはり「ディスクへの指紋付き」などが悩みのようです。
これを防ぐための手段がないのなら分かるのですが、手袋で容易に防ぐ事ができますので、
これらが平然とまかり通っているのはちょっとね・・という内容でした。
※ プラッタ(ディスク表面)への指紋付着は致命傷(復旧不能)となります。

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

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

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

ヘッド交換技術 [ヘッドアンロード, CSS方式]

各ヘッドの集まり IBMサーバ

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

ヘッド交換のおさらい

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

プラッタ移植技術 [モータ焼けに対応]

東芝製ハードディスク 40GBのハードディスク

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

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

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

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

DIRECTSCAN

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

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

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

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

シングルスレッド
マルチスレッド

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

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

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

旧技術の回避システム 新技術の回避システム

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

ここまで、以上です。

5月29日(土) 内容のまとめです。
※ スキャン結果の解析についてまとめました。

FromHDDtoSSD 3D 詳細解析

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

FromHDDtoSSD 3D 詳細解析 2

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

ここまで、以上です。

6月19日(土) 内容のまとめです。
※ 物理障害データ復旧の改善と、メモリ管理(DIRECTSCAN Ver2.0, FromHDDtoSSD Ver2.0)

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

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

FromHDDtoSSD メモリ管理

ここまで、以上です。

8月21日(土) 内容のまとめです。
※ SSD データ復旧に関して 1回目&仮想化環境に関する考察 1回目

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

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

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

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

SSDに対する全スキャン

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

約 32,000時間使い込みましたウエスタンデジタル製 ハードディスク

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

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

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

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

ここまで、以上です。

9月23日(木) の内容 ここから・・・

故障予測技術

予定より大幅に遅れておりました「故障予測」方面の報告です。
遅くなりまして、大変申し訳ございません。
従来の技術を大幅に改良した「新型(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日)

ここまで、以上です。

10月11日(月) の内容 ここから・・・

故障予測スキャンモニタ Ver2.0Aにて完成しました

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

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

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

ここまで、以上です。

10月23日(土) の内容 ここから・・・

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

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

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

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

ここまで、以上です。

12月19日(日) の内容 ここから・・・

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

リカバリエディション

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

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

ここまで、以上です。

※※ 2011年 技術報告 ※※

2月20日(日) の内容 ここから・・・

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

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

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

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

リカバリエディション

ここまで、以上です。

6月5日(日) の内容 ここから・・・

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

メインコントロール

DIRECTSCANでも厳しい場合、次の手といたしまして「ヘッドレストレーション」を使います。
なお、上のスクリーンショットは自動制御のみの「公開」バージョン(>> FromHDDtoSSD Ver2.0Cへ搭載)です。
データ復旧業務では手動による制御変更(コマンド)をサポートした専用バージョンを開発・採用しております。

これでも厳しい場合は「クリーンルーム作業」にて修理を必要とするレベルと判断いたしております。
※ 初期診断作業に関しまして重要な点が、ここに存在いたします。
僅かな差でも、処置方法が大きく異なるためです。(このようなミスは、後々大きくなって厳しい状態となります)

ここまで、以上です。

並列同時解析が完成いたしました。

並列同時解析の例

色々と^^;)ありましたが、ようやく並列同時解析の稼動まで辿り着くことができました。
誠にありがとうございます。

ここまで、以上です。

12月18日(日) の内容 ここから・・・

イメージを保管する作業用ハードディスクを並列処理へ参加させ、
現在のスキャン状況を解析しつつ、その作業用ハードディスクを上手く活用し、
危険度の高い区間を上手くバックアップしながら解析を並列処理する方向へ改良します。
※ 現在の方式では、損傷ディスクを解析する際、正常な区間に限り並列処理できます。
そのため、損傷が進んでいる場合、保留中区間が延び過ぎてしまい、
並列処理の恩恵が薄れてしまう欠点がございます。(保留中を作業用へ移行し、並列処理できれば・・)

ここまで、以上です。

※※ 2012年 技術報告 ※※
新しい物理障害(2.0TB以上のHDDに発生)に関する内容からスタートいたしました。
「変わった症状」となっておりまして、よく他業者様からもご相談を受け賜わっております。
復旧自体は可能ですが、原因の特定がやや不安定となっておりますので、現在も探求が続いております。

1月9日(月) の内容 ここから・・・

「新しい物理障害」を取り扱いまして、その原因等の解析に関する内容となりました。
2.0TB以上の大容量ハードディスクに発生する障害となっておりまして、
読み出し速度が数秒にてほとんど0まで低下し、反応が得られなくなります。

しかしながら、僅かですが読み出すため、そのままスキャンを行うケースも伺いました。
結果から先に書きますと、1秒間に数バイトしか読み出せず、断念に至ったとのことです。
現在、このケースの復旧には読み出し速度が低下する「数秒」という時間を出来る限り伸ばしまして、
さらに、速度が完全に低下する前に転送を完全に止め、回復を待ってから再開する手法を採用しております。
※ 上のスキャンを繰り返し読み出しまして、安定状態となるポイントを探り、自動制御に移行します。
上の方法にて、このケースにおける全てのご案件を成功いたしております・・・が、
ここで問題となるのは「原因」です。原因が曖昧なままデータ復旧が先行している状態は好ましくありません。
この障害を起こしましたハードディスクをお譲りいただき、探求を続けております。
なにとぞよろしくお願いいたします。
ここまで、以上です。

データ復旧総合環境の徹底検証:2012年8月1日(水)~2012年8月5日(日), 2012年8月14日(火), 2012年9月10日(ベータ版検証完了)

並列同時解析の例
先頭セクタ番号

実稼動に向けて、徹底的な検証を行います。
問題点の検出を優先的に行いまして、次に操作性を追及いたします。
※ これにてくまなく問題点を列挙し、修正のち実稼動させる見込みです。=>完了いたしました。
残るは、不良セクタ予測リンク方式に関する最終調整です。=>完了いたしました。
※ 正式版一歩手前(最終テスト版)のバージョンを配布いたします。
これで問題ない場合、いよいよFromHDDtoSSD Ver2.1を公開いたします。色々とお手数をおかけし、大変申し訳ございません。
ここまで、以上です。

FromHDDtoSSD Ver2.1 正式版リリース:2012年10月17日

データ再構築を完了
誤フォーマットから復旧

FromHDDtoSSD Ver2.1を公開いたしました。
一旦、このバージョンにて半年様子を伺い、目立ったバグを全て修正いたします。
※ Ver2.1より、ビルド番号で管理しておりますので、バグフィックスが楽になりました。(ビルド番号方式のご提供、ありがとうございます)
ここまで、以上です。

※※ 2013年 技術報告 ※※
完成に近づいてきました。重要な部分に限り、まとめて更新していきますので、よろしくお願いいたします。

FromHDDtoSSD データリスト連動機能について

認証してアクセス => データリスト表示

内部が統一され、データ復旧サービスと統合できる状態になりました。
まず、データリストをこちらに統合いたしまして、使い易くいたします。
ここまで、以上です。

※※ 2014年 技術報告 ※※
完成に近づいてきました。重要な部分に限り、まとめて更新していきますので、よろしくお願いいたします。
ドライブリアルタイム解析の同時スキャン(並列スキャン)に成功いたしました。心配だったメモリ周辺のバグもなく、順調です。

ホコリ前提復旧は、最も過酷な状況(フタが空いた状態)でスキャン(データ復旧)が通るように調整・デバッグしております。
使い道の方は、自分でヘッド交換を行われた場合に、ホコリが入り込んでもスキャンを通すために利用します。リカバリエディション以上で対応いたします。
最も厳しい「蓋を開けた状態」でデバッグする事により、実際の利用状況下(一度は開けたが、その後は閉めている)ではさらに安全になります。
現在はスキャン系単独で調整しておりますが、間もなく、ファイルシステム別の調整が入ります。これで、100%の力を出せると思います。

ホコリ前提復旧_1 ホコリ前提復旧_2

ホコリ前提復旧機能にて、「デバッグ」&「ビッグデータ化」を進めております。

ここまで、以上です。

4月29日~5月3日 (ゴールデンウィーク中) 期間中の内容
※ ドライブリアルタイム解析で、不良セクタの位置を事前に決めていき、回避していきます。
データ復旧で最もリスクが高いのは磁性体剥離の不良セクタに何度もヘッドを当ててしまい、動作不能にしてしまう事です。

※ 統計スキャンの心臓部となる「ドライブスタビリティコントロール」(右側ダイアログ)です。
このダイアログはモードレスで設計いたしましたので、このコントロールとスキャン部(左側)を同時に操作する事ができます。
統計スキャン

ここまで、以上です。

5月6日 最後の課題:CPUの稼働率
統計スキャンの復旧機能への適用(システムリカバリ)に向けて
※ 1~4台の並列処理に成功いたしました。システム負荷は40%~60%(4コア稼働)となっております。
※ Hyper-Threadingでは、余裕がないためか、逆に低下する場面もありますので、実コアの数で勝負となりそうです。
※ 見た目だけコア数増やしても・・、テクニカル的な面で搭載ではなく、マーケティング的な意味合いかもしれません。
そもそも、Hyper-Threadingはスカスカの部分の穴埋めとして出てきたものだったような・・気がいたします。

システムリカバリ

※ CPU稼働率は、まだ高めです。ただ、大事な部分を切る訳にはいかないため、アルゴリズムの方で調整いたします。
データ復旧機能&スキャン機能&つなぎ&ビッグデータ解析の並列処理で「50%程度」に抑え、緊急回避分の余力を残しておきます。
CPU使用率

ここまで、以上です。

7月12日「つなぎ復旧 / ミリセカンド検査」の検証
暑い中、ありがとうございます。
偶然的に出来た機能なのですが、検査はもちろん、色々と応用が利きそうな機能となりました。
危険回避につきましては自動制御しかない(人の判断では間に合わない)のですが、このグラフの変化を利用して、もう少しスキャン速度を高める試みを実施しております。
※ 上に張り付いている場合は、中間よりも明らかに余裕がありますので、スキャンを打診的に上げていき、復旧時間の短縮を図ります。

ホコリ前提復旧

ここまで、以上です。

2014年8月より、大容量HDD(特にSeagate製の2.0TBが「ほぼ毎日」・・)が急増しております。
スキャンが通りにくく、出来る限り最小限の調査でデータを復旧していく技術が必要となりました。
そこで、昨年10月より着手いたしましたビッグデータ解析を利用し、頻度曖昧検索を開発いたしました。

ファイルシステム全体の形状等からファイル使用頻度を割り出す頻度曖昧検索機能は、
ファイルの配置などを元に解析し、ファイルに優先順位を付ける事ができます。
この優先順位が、データ復旧にとても役に立ちます。色々と使える汎用的な解析情報です。

頻度曖昧検索

ここまで、以上です。

2014年9月:
2年以内製造のドライブの故障が多く見受けられるようになりました。
パソコン内蔵、外付型、NAS、RAID、TeraStation等、あらゆる所で似た故障となっておりますので、状況的な要素を集めただけでも、ドライブ自体の問題となりそうです。
さらには、これらドライブが故障いたしますと、クリーンルーム作業等を実施後でも、その制御の幅が非常に狭く、制御自体が難しい問題がございます。
このため、Windowsからの制御だけではなく、他の色々な装置(自社開発)を利用し、部分的に自動制御・独立化させて復旧する見込みとなりました。

□ 外部制御用の試作品(右側の画像)です。こちらはすでに完成いたしまして、ユニバーサル基板に移植(はんだ付け)させて稼動しております。
Windowsソフトウェアだけでは届かない部分(準備等で誤り易い部分なども含む)を、自動制御化しつつ上手く処理させております。
(実際にはパソコンと直接接続いたしますと、正確な時間以外の要素は全部書けるのですが、効率・安全の面で「独立」させた方が間違いがないためです)
ヘッドクラッシュ 外部制御の試作段階

ここまで、以上です。

2014年10月~11月:
ビッグデータ解析の方も、いよいよ大詰めです。
大量の統計データから、利用可能なデータの取り出しに変形するデータマイニングの実装に取り掛かり、11月より稼動いたしました。
まだまだ改良の余地あり(誤差が出ますと、グラフが大きく変形する)なのですが、来年の4月までには、この誤差を最小限に抑えられるように調整いたします。
※ 利用可能なデータの取得よりも、不要なデータの破棄に、この問題点を改善する鍵があるとみております。
この、大きくデータがずれる点は、早めに何とか片付けたいところです。

データマイニング

ここまで、以上です。

2014年12月より ドライブ故障統計(ビッグデータ)と通信開始:
先月、ビッグデータの解析部分(データマイニング)を稼動いたしました。
いよいよ、その解析結果を積んだデータベースと、FromHDDtoSSDが通信を開始いたします。
※ 通信部分の追加および、通信が途切れてしまうバグを全て修正いたしましたので、問題なく安定いたします。
※ 誤差に関しましても、上手く処理する方法が見つかりましたので、それを試しております。

ストレージ故障予測&データマイニング

ここまで、以上です。

2015年1月より ドライブ故障統計(ビッグデータ)の運用開始:
昨年はビッグデータの開発を行っておりまして、いよいよ、2015年より運用を本格化いたします。
これらのデータの蓄積&データマイニングにより、対象ドライブの特性および近似値を少ない要素から導くことができ、
ATAコマンドで取得できなかった部分や、取得にリスクを伴う部分(データ復旧にて「壊れかけ」の場所を調べなくて済みます)をノーリスクで補填できます。
僅かな差が「大きな違い」になる場合が多くございまして(特にデータ復旧)、それらを解決できる新しい解決方法です。

ストレージ故障予測&データマイニング

ここまで、以上です。

2015年3月より S.M.A.R.T.コンセンサス
ドライブの状態を素早く解析するS.M.A.R.T.コンセンサスをリリースいたしました。
ドライブが正常ならば、この解析で十分に判断する事ができるようになっております。
ただ、壊れかけのドライブには不十分です。さらに深く解析できる「統計スキャン」の完成を急ぎます。
※ 現在でも手動で初回のみパラメタを与えれば十分に動かせる(弊社の復旧サービス)のですが、出来る限りの自動化を施しいたします。
(それらパラメタ自体が説明しにくいためです)

S.M.A.R.T.コンセンサス

ここまで、以上です。

2015年4月より、NTFSおよび、FAT(12/16/32/exFAT)が不良セクタ危険予知(つなぎ復旧)に対応いたしました。
これにより、深い位置へのスキャンを安全に実行できるようになりましたので、二段階解析を解放いたしました。
この解析は全てのエントリを必ず再帰させる方法となりまして、スキャンの割合が大幅に増加するため、リスク管理が必要です。
不良セクタ危険予知より、リスク管理システムが確立できましたので、今後も復旧機能を解放していきます。

なにとぞよろしくお願いいたします。

ここまで、以上です。

2015年6月6日 2015年6月28日 自動復旧に関する調整(打ち合わせ)を行います。
※ 重要な部分は自動制御となっております。実際に壊れかけドライブを持ち込みますので、お確かめ下さい。
※ 機械学習の右腕となる「状態変化サイン」の投入を完了いたしました。これで「完成」です。

なにとぞよろしくお願いいたします。

ここまで、以上です。

技術の方がほぼ「完成」いたしましたので、次はWebサービスです(^^;
第一弾として、大量のドライブ故障統計を利用し、ドライブの状況を解析いたしました「全国ドライブ情報」をリリースいたします。
これらの情報はデータ復旧の壊れかけドライブ悪化防止などにも役に立てておりまして、最後の復旧チャンスを生かします。

2015年9月:全国ドライブ情報の下部に、新しく開発いたしました「ドライブマイニング」を付け加えました。
この機能は、ドライブ故障予測(ビッグデータ)をより細かく解析・判断して説明する機能となっております。
※ メーカさん&ドライブ別に気が付いた点を次々と自動的に追加する仕組みとなっております。成り行き任せで順不同です。

ドライブマイニング

SMRに関するドライブに対応いたしました。
※ 独特な動きをいたしますので、少し変えないと厳しい結果となりました。
容量を上げるために重ね書きした部分のビット腐敗の割合などが気になるところ(^^;です。
ビット腐敗の割合とヘッドの消耗度はスキャンの位置・速度を決めるための大きなパラメタとなっているためです。

なにとぞよろしくお願いいたします。

2016年1月 ハードディスク落下=>故障に備えるデータ復旧技術

ドライブ故障統計(ビッグデータ)を利用いたしまして、ハードディスク 落下耐久性を数値化いたしました。
これは、現在開発しておりますレベル2(補助付きの自動制御)のデータ復旧に採用させていただく見通しです。
※ 落下させてしまった壊れかけハードディスクの自動制御に成功いたしておりますので、あとは詰めるだけ(^^;です。

なにとぞよろしくお願いいたします。

2016年2月 R.E.C.O.A.I.(機械学習スキャン&人工知能) ハードディスクのデータ復旧に採用

デバッグ等も完了いたしまして、ハードディスクのデータ復旧に採用を開始いたしました。
従来の手作業による復旧の限界を「機械学習」で吹き飛ばします。10.0TB 20.0TBでも問題ありません。
※ 必ず最後までスキャンを通せますので、業者への依頼でよくありがちな中途半端な結果(2割位しか出ていない)はありません。
壊れかけドライブの状態を弊社独自開発のアルゴリズムで「数値化(20通り)」いたしまして、ビッグデータを利用しつつ学習させる手法を採用しております。 1回限りとされるデータ復旧チャンスを生かすために、研究を重ねてまいりました。
本成果はデータ復旧に限らず、ドライブの故障予測機能などにも積極的に活用しておりまして、こちらはフリーソフトウェアの形で公開いたしております。 誰にでもご確認いただけるオープンな取り組みです。

なにとぞよろしくお願いいたします。

2016年2月 ハードディスク 悪化傾向の数値化 (悪化耐久指数)

ドライブ故障統計(ビッグデータ)を利用いたしまして、ハードディスクの悪化傾向を数値化いたしました。
※ ドライブ悪化に関する研究は、特に問題なく進んでおりまして、それを活用して機械学習スキャンを動かしております。

なにとぞよろしくお願いいたします。

2016年4月 ハードディスク 型番別注意

全体のドライブ故障統計より、特に注意が必要な型番についてまとめました。

なにとぞよろしくお願いいたします。

2016年5月 プラッタ方面の劣化を主眼に置く プラッタ指数

ハードディスクの劣化をヘッド・プラッタの2方面に分けまして、そのうちのプラッタ方面に関する指数となります。
磁性体剥離、プラッタ歪みなどの影響は、その動作のクセからしっかり取り出すことができます。
ヘッド方面は悪化耐久指数、プラッタ方面はプラッタ指数にて、それぞれの劣化具合を独立させて測定いたします。
※ 大きく値が動いた場合、これで不具合を特定することができます。不具合の特定は、データ復旧技術に不可欠です。
自動復旧を導入する場合、このような数値を学習させて変化を見ていく過程が心臓部に相当いたします。順調に開発が進んでおります。

なにとぞよろしくお願いいたします。

2016年9月 AI完全自動ドライブ復旧システム ベータ版

まず、ベータ版となりますが、自動復旧の一部を搭載いたしました。

なにとぞよろしくお願いいたします。