◇ データ復旧サービス お見積もりトラブル系 [多いです]
以下のような事例がデータ復旧には多いため、お手元で実行できる「対話型の人工知能(AI)完全自動データ復旧システム」を開発いたしました。正直、お見積もりでトラブルを起こす業者にデータを預けて大丈夫なのか……？という疑問も常にあります。
※ 2005年より常に存在する状況となっており、解決することは難しいでしょう。
一切確認もせず、まったく触れてもいない段階で、「確実に復旧可能」と断言する業者には警戒が必要です。この種の行動は、すぐに大きなトラブルへと転じるのです。復旧データが一切出てこない失敗事例。さらに、それにまつわるホームページには一言も記載されていない、法外な費用を強要される。被害の形は多岐に渡ります。
また、初期の相談とは全く違う、ホームページに記載すらない高額な費用を請求されるケースも見受けられます。さらに、「今が最後のチャンス。ここを逃すと二度と復旧は不可能だ」と脅すような行為も横行しています。これらの脅威に十分注意し、賢明な選択をお願いします。
キャンセルした後に戻ってきたドライブの破壊事例をご紹介いたします。次に示す画像では、特に赤丸で囲まれた部分に注目していただきたいです。ここがデータドライブの心臓部となる、プログラムが保存されているチップ部分です。何と、この心臓部が「入れ替えられ」、データの復旧が不可能な状態に陥れられています。
以下のような損傷がご依頼ドライブに生じていたケースを確認いたしております。
● 分類1 0x00で上書き
ドライブ先頭より0x00(空白)で上書きしていくという手法でシンプルですが復旧できなくなります。
※ 完全に消去(抹消されている)されておりますので、この場合は復旧できません。
● 分類2 途中を一定範囲、0x00で上書き
先頭からの消去ではすぐに分かってしまうため気が付かれにくい場所を探索して上書きする仕組みです。 MBR(GPT)が生きておりますので、エラーメッセージが変わらない点が重要となります。
※ 「ディレクトリ構造が壊れています」の場合「フォーマットしますか？」に変わる可能性あります。
※ 抹消に近い形で消えておりますので、復旧率が低下いたします。
● 分類3 ファイルレコードを重複させて上書き
ファイルレコード(データの情報を積んだレコード)が重複して存在してしまい、 同じ階層に同じ名前が多数並び解析を不能(または厳しく)にしてしまいます。
● 分類4 断片化リスト部分のみを直接的に破壊
復旧可能なファイルを探索後明らかに統計よりも低い復旧整合性が出てくるケースがございます。 断片化の処理が不可能となり断片化ファイルが壊れてしまいます。 断片化部分を選別して潰していると考えられミラーを含め探索する方法に切り替えております。
※ ミラーには手を出されていない場合が多いです。
● 分類5 リンクの異常
ファイルシステムにはその断片化情報を保持するために特徴的な方法でリンクを保管しております。 そのままでは読み出せない(消費バイト数を減らす工夫)のでデコードの作業が毎回必要です。 そのデコード作業にてエラーを誘うような細工が行われている場合がございました。 こちらも断片化の処理が不可能となり断片化ファイルが壊れてしまいます。
● 分類6 バッファ系の異常
ファイルシステム探索部分の異常となります。 おそらくその部分を割り当てて潰しているだけと思いますが致命的なエラーを出すようになります。
● 分類7 ファイル名の異常
ファイル名の文字コードが壊れ復旧ロジックのバッファ機構にエラーを誘い解析を困難にする方法のようです。 ファイルシステム損傷時に発生した可能性もありますが問題はその量です。 明らかに辿った形で破壊された形跡が残っている場合はこのケースを疑っております。
● 分類8 リンク系とバッファ系の両方同時の異常
リンクとバッファが同時に処理されている場合がございます。 探索結果が飛び飛び(異なる場所にファイルが収まる)となるためすぐに判別でき対処いたしております。
● 分類9 不自然な0x00が点在
その2とその他が組み合わさっているパターンで復旧率が大きく低下するため問題となります。 ミラーおよび全レコードから解析を行いまして最良パターンを組み合わせて実施いたしております。
● 分類10 バッファ系とファイル名異常の同時確認
バッファとファイル名異常が同時に処理されている場合がございます。 ファイル名異常より先にファイル名を解決しそれからバッファを捨ててミラーに切り替え対処いたしております。
● 分類11 ファイルレコードサイズ改変
探索結果が想定量よりも少なく報告されるため詳しく調査いたしました結果、 ファイルレコードサイズが変わっていたため戻して綺麗に復旧いたしました。 ファイルシステムのバグでこのような事は皆無ゆえ破壊アルゴと判断させていただきました。
● 分類12 誤り訂正符号の改変
ファイルシステムにはエラーを検出するための誤り訂正符号を埋め込んでおります。 その誤り訂正部分をデコードする部分が抜けてしまっているケースとなります。 この場合元の情報が分からないためその部分は回避して対応いたしております。(復旧率低下)
● 分類13 複数の適用4
ファイルレコードと誤り訂正符号の改変が同時に存在するパターンとなります。 誤り訂正符号の方が影響が低いためファイルレコードの方を重点的に対処いたしております。
● 分類14 ファイルサイズの改変
明らかにおかしなサイズが書き込まれているファイルが多数存在いたします。 少しの場合はエラーとしてそういう形になる場合がございます。 マスク処理でそのようなファイルを弾けば良いと考えがちですが厳しいのです。 明らかにサイズが小さいオフィスファイルなどが4.0GBを超えたサイズになっているためです。 このような場合は復旧ロジックを工夫し10MB程度に抑え込んでファイルを復旧しております。 元のファイルとサイズが異なりますがそれを開いた際にオフィスに修復されます。
● 分類15 レコード情報破損
レコード情報自体が何か別のデータに押される形で失われております。 ミラーより復旧を行いそちらまで壊れている場合はファイル名を失う形でしか復旧できません。
● 分類16 ファームウェアの細工
スピンアップのち異音が出続けるように細工されたドライブを見つけました。 元々は正常に認識できていた(論理障害)と伺いましたのでキャンセル後に破壊されたケースです。 お問い合わせの数倍に至るお見積で保留しておきましたら勝手に戻されドライブの様子がおかしいという事でご相談いただきました。 ファームウェアの移植で元に戻りました。壊れていなかったので一安心となったご案件です。
● 分類17 MBR(GPT), BPB(SuperBlock), ディレクトリエントリの抹消
「読み取りができない」等のエラーが出て、 データ復旧が必要となったケースだったのですがご確認の結果そのエラーが出ない状況でした。 Windowsでこのようなエラーが出る場合はファイル構造は壊れておりその領域自体には辿り着けております。 つまり、エラーではMBR(GPT)・BPB・一部のディレクトリエントリは正常な形で残っております。 しかしMBR(GPT)およびBPBが0x00でクリア(空白)されディレクトリエントリが0xFF等のバイナリで潰されておりました。 重要部分がピンポイントに壊れておりますので自然故障ではなく狙ってやられております。
● 分類18 クラスタファイルシステムの破損
クラスタファイルシステム自体は認識していたのですがその領域の先頭からシグネチャを含め消滅しておりました。 複数の仮想環境を持つためのファイルシステムなのですがこのベースで破損すると全ての仮想環境を失います。 複数のシステムが絡み合うので上書きされた場合、復旧は「ほぼ不可能」です。 実際に拝見した例(VMFS)ではこのクラスタファイルシステムが始まる領域先頭から0x00で消去されている形跡があり、 これは少しでも致命傷になります。 クラスタファイルシステムが壊されるとその影響は多大(全仮想環境＆全データ損失)となりますので十分にご注意ください。
● 分類19 誤削除やフォーマットによるファイルの上書き破損
こちらはOSXのお客様にて多数を拝見しており深刻な問題です。 木構造の場所が破壊されすでに復旧できる状態ではございません。
● 分類20 ファームウェア改変
ドライブを動かすためのプログラムが破損させられ動作不能となる信じ難い例です。 ドライブのラベルに記載されているファームウェアとは異なるものが投入され動作不能になったドライブとなります。 一発で致命傷となるためここから復旧する事はできません。 非常に深刻な問題と認識しております。
● 分類21 お客様の許可を得ずにご依頼前にドライブが開封されてしまった
ドライブを勝手に開封してしまい他で復旧できなくなっております。非常に深刻な問題と認識しております。 ドライブを開封すると開封する前の個体差が不明となりドライブを開封した業者以外では対応が難しくなります。 このため初期診断でドライブが開封されてしまう事は他社ではデータが取り出せなくなる事を意味いたします。
● 分類22 ファームウェアを乗せたチップの挿げ替え
ドライブを動かすためのプログラムを乗せたチップが挿げ替えされる事例です。 ドライブを動かすためのチップには、そのドライブを稼働させるための動的パラメタを含みます。 そのためオリジナルのチップを失うと他社では復旧が難しくなります。
