データ復旧サービス

データ復旧作業において、重要な工程の一つに、データ整合性検査があります。これは、ファイルシステムが、データの管理領域と実データを分けて管理していることに由来します。ファイル名、フォルダ構造、サイズ、配置情報などは、主に管理領域、いわゆるメタ情報として管理されています。一方で、実際のファイル内容は、別の領域に実データとして記録されています。つまり、管理領域だけを確認できても、それだけで実際にデータが復旧できるとは限りません。メタ情報を解析し、その先にある実データを読み出し、必要に応じて断片化したデータを組み合わせる。そして、実際に開けるファイルとして成立した段階で、はじめて復旧可能だったと判断できます。そのため、データ復旧では、単にファイル名やフォルダ構造が見えるだけでは不十分です。復旧されたファイルが、実際のデータとして整合しているかどうかを確認する必要があります。この確認作業が、データ整合性検査です。

ドライブのラベルに記載されている容量と、Windowsなどで表示される実際の容量には差があります。これは、容量の数え方が異なるためです。一般的に、ドライブメーカーは10進数で容量を表記します。たとえば、1TBは1,000GBとして扱われます。一方で、WindowsなどのOSでは、2進数を基準にした容量表示が使われるため、同じ1TBのドライブでも、表示上は約931GBのように見えることがあります。この差は、容量が大きくなるほど目立つようになります。そのため、大容量HDDやSSDでは、ラベルに書かれた容量と、実際にOS上で確認できる容量の差が、かなり大きく感じられることがあります。

ドライブに対してベンチマークを実施し、その結果からドライブの状態や寿命傾向を判断する手法があります。このとき重要になるのが、正常な数値からどれくらい離れているのか、という点です。当サービスでは、この差を乖離率として捉え、グラフ化することで、ドライブの異常傾向を瞬時に見抜ける仕組みを開発しております。たとえば、同じ種類や同じ容量帯のドライブであっても、正常な個体であれば一定の範囲に収まる傾向があります。しかし、動作不良や全体的な劣化が進んでいるドライブでは、その数値が正常範囲から大きく外れることがあります。

データ復旧では、ドライブの修理作業を行うことがあります。特にハードディスクの場合、クリーンルームを活用した分解作業を思い浮かべる方も多いと思います。しかし、それはあくまでデータを取り出すための手段であり、必ず必要になる作業ではありません。目的は、ドライブを分解することではありません。目的は、失われたデータを可能な限り安全に取り出すことです。ここで重要なのは、データ復旧とドライブ修理は同じものではない、という点です。

このたび、「業界の最新動向をキャッチ！Web3技術が分かる情報メディアまとめ」に、データ復旧・解析関連として掲載していただきました。暗号関連の復旧技術をはじめ、壊れかけたドライブに対する復旧処置、暗号の規則性に関する考察、さらにドライブの組み合わせであるRAIDに関する検証などについて、ご紹介いただいております。データ復旧・ドライブ解析・暗号技術・Web3領域は、それぞれ別分野のように見えますが、実際にはデータの保全、検証、信頼性という点で深く関係しております。今回、このような形で取り上げていただき、大変ありがたく思っております。今後とも、なにとぞよろしくお願いいたします。

エラーメッセージが表示されたあと、そのまま固まってしまう場合と、すぐに電源が落ちる、または再起動してしまう場合があります。この二つは、似ているように見えて、疑うべき原因が異なります。まず、エラーメッセージが表示されたあとに、そのまま固まってしまう場合です。この場合、OSが格納されている内蔵ドライブ、つまりWindowsが動作しているドライブに異常が生じている可能性があります。

ドライブが故障したときに表示されるエラーメッセージ。この20年以上、それも研究対象の一つとして、データ復旧の改善に活用してきました。ドライブが故障したときの動作は、必ずしも安定しているとは限りません。そのため、表示されたエラーメッセージと、実際のドライブ故障状況が一致しない場合も多くあります。そこで今回は、エラーメッセージとドライブの故障状況を比較しながら、どのような状態が考えられるのかを見ていきます。

RAIDを考えるうえで、まず大前提となるのは、RAIDはバックアップではないという点です。どのRAID構成であっても、重要なデータを守るためには、別媒体へのバックアップが必要になります。これは非常に重要です。RAIDは、あくまでドライブ故障時の稼働継続性を高めるための仕組みです。そのため、RAIDを組んでいるからといって、データが完全に保護されているわけではありません。構成としては、ドライブ台数が少ない場合にはRAID 5。台数が増えてきた場合や、より余裕を持たせたい場合にはRAID 6。このあたりが、比較的現実的な選択肢になってきます。

複数のドライブを組み合わせる方式の一つに、スパニングがあります。スパニングとは、ストライプサイズを設けず、複数のドライブをそのまま順番につなげて、一つの大きな領域として扱う方式です。ストライピングのように、複数のドライブへ同時に分散して読み書きするわけではありません。そのため、基本的には読み書き性能の向上は期待できません。また、ミラーリングやパリティのような冗長性もありません。

ミラーリングとストライピングを組み合わせることで、両方の利点を得ようとする構成があります。それが、RAID 10やRAID 01です。RAID 10は、ミラーリングした組をさらにストライピングする構成です。一方、RAID 01は、ストライピングした組をさらにミラーリングする構成です。いずれも、ミラーリングによる冗長性と、ストライピングによる速度向上を組み合わせようとする考え方です。

RAID 5では、1台のドライブ故障に耐えられるように、パリティ付きストライピングという構成が採用されています。これに対して、構成されているドライブのうち、最大2台までの故障に耐えられるようにしたものが、RAID 6です。RAID 6は、分散ダブルパリティ付きストライピングとも呼ばれます。RAID 5では、1台のドライブが故障した時点で、残っているドライブに高い完全性が求められます。つまり、故障した1台分のデータを復元するには、残存ドライブから正しくデータを読み出せることが前提になります。

ここで、1台のドライブを失っても稼働を継続できる分散型のドライブ構成として登場するのが、RAID 5です。RAID 5は、パリティ付きストライピングと呼ばれる方式です。ストライピングによって複数のドライブへデータを分散しながら、同時にパリティ情報を記録します。このパリティ情報を利用することで、構成ドライブのうち1台が故障しても、失われたデータを計算によって復元できるようになっています。基本的には、各ストライプ単位でデータブロックとパリティブロックを配置し、排他的論理和、つまりXORによって整合性を保つ仕組みです。

RAIDの中でも、データ保護装置と勘違いされやすいのが、ミラーリングです。ミラーリングは、確かに複数のドライブへ同じ内容を書き込む方式です。そのため、1台くらい故障しても大丈夫。そう考えたくなる気持ちは、よく分かります。しかし、それでもミラーリングはバックアップではありません。まず重要なのは、RAIDではOSと各ドライブの間に、RAIDコントローラやRAID管理層が入るという点です。OSは、RAIDを構成している個々のドライブを直接扱っているわけではありません。OSから見ると、RAIDコントローラが提示する一つの論理ドライブにアクセスしている形になります。

まず、RAIDの基本的な構成の一つである、ストライピングについて見ていきます。ストライピングとは、複数のドライブに対して、決められたストライプサイズごとにデータを分散し、交互に読み書きしていく方式です。複数のドライブへ処理を分散できるため、読み書き性能の向上が期待できます。特に、連続した大きなデータを扱う場合には、単体ドライブよりも高速に処理できることがあります。しかし、その一方で、ストライピングには冗長性がありません。

RAIDは、複数のドライブを組み合わせて動作させる仕組みです。もともとはバックアップを目的としたものではなく、主な目的はシステムの稼働継続性を高めることにあります。つまり、ドライブの一部に障害が発生しても、できる限り運用を継続できるようにするための仕組みです。それでは、RAIDではどのようにデータを格納しているのでしょうか。ここから、その基本構造を見ていきます。まず重要になるのが、ストライプサイズと呼ばれる単位です。