LinuxベースのNASで破損したRAID 5アレイからデータを回復する

ある組織の典型的な平日は、通常のプロセスがすべて停止したため、数十人が活動を継続できなかったため、平凡なものではなくなりました。 CRMは作業を停止し、マネージャーベースは応答を停止しました。同様の状況が会計データベースにも見られました。 システム管理者には、問題や緊急の介入要件に関するメッセージとともに、ユーザーからの電話が殺到しました。 最近この会社でキャリアを始めたシステム管理者は、 NASに接続しようとしましたが、デバイスが応答しなかったことがわかりました。 電源をオフにして再びオンにした後、NASは復活しましたが、仮想マシンは起動しませんでした。 ユーザーは共有ファイルストレージのみを利用できました。 システム管理者による問題の分析は、2つのRAIDアレイの1つにボリュームが含まれておらず、純粋に未割り当てのスペースであることを示しました。 システム管理者のさらなる行動が何であったか、物語は沈黙しているが、彼は会社のデータと作業環境を復元するための明確な行動計画がないことにすぐに気づいた。 この段階では、このNASの6台のハードディスクドライブ（2台のHDD-3 TB HDS5C3030ALA630、4台のHDD-4 TB WD4000FYYZ-01UL1B1）を自由に使用できます。 参照条件では、「パーティションテーブルの復元」に招待されています。







もちろん、このようなディスクのボリュームでは、従来のパーティションテーブルについては一切話せません。 安全な作業のために、各ドライブのステータスを評価して、セクターごとのコピーを作成するための最適な方法を選択する必要があります。 これを行うには、 SMART測定値を分析します。また、密度の異なる領域の各ヘッドの小さなセクションを読み取ってBMGのステータスを確認します。 私たちの場合、すべてのドライブが動作していることが判明しました。



実行時間を最適化するには、ディスクの先頭から100,000,000セクターのコピーを作成します。 ドライブのセクターごとのコピーが作成される間、分析のためにこれらの50ギガバイトのイメージが必要になります（完全なコピーを作成することは必須の保険ですが、時にはデータ回復手順を遅らせるだけのイベントはそれほど重要ではないようです）。



NASがディスクでどのように機能し、どの論理パーティションツールが使用されるかを理解する必要があります。 これを行うには、各ドライブのLBA 0および1を調べます。





図 2



オフセット0x01C2の3TBドライブには、パーティションタイプ0xEEが書き込まれ、LBA 0x00000001から生成され、そのサイズは0xFFFFFFFFセクターです。 このエントリは、 GPTを使用するドライブの一般的なセキュリティエントリです。 GPTが使用されていると仮定して、画像内の0x200に由来するセクター1のコンテンツを評価します。 正規表現0x45 0x46 0x49 0x20 0x50 0x41 0x52 0x54（テキスト形式：EFI PART）は、GPTヘッダーがあることを通知します。

セクター2には、GPTパーティションエントリがあります





図 3



最初のエントリは、0x0000000000000022セクターから0x0000000000040021セクターまでのセクションを記述しており、このセクターは標準に準拠していないGUIDを持っています。 開発者からの感嘆符が含まれています。 EFIは必要ありません。 ボリュームラベルは「BIOSブートパーティション」です。



2番目のエントリは、0x0000000000040022セクターから0x0000000000140021までのセクションを記述します。このセクションの識別子はA19D880F-05FC-4D3B-A006-743F0F84911Eです。 ボリュームラベルは「Linux RAID」です。



3番目のエントリは、0x0000000000140022セクターから0x000000015D509B4Dセクターまでのセクションを説明します。これにはGUID A19D880F-05FC-4D3B-A006-743F0F84911Eもあります。 ボリュームラベルは「Linux RAID」です。



パーティションのサイズに基づいて、1つ目と2つ目は無視できます。これらのパーティションはNASのニーズに合わせて作成されていることが明らかだからです。 3番目のセクションは、現時点で私たちが興味を持っていることです。 識別子によると、Linuxによって作成されたRAIDアレイのメンバーのサインがあります。 これに基づいて、RAID構成のスーパーブロックを見つける必要があります。 セクションの先頭から8セクターまでの予想される場所。





図 4



この例では、オフセット0x0で、正規表現0xFC 0x4E 0x2B 0xA9が見つかりました。これはRAIDスーパーブロックのマーカーです。 オフセット0x48では、このブロックにRAID 1アレイ（ミラー）が記述されていることを示す値0x00000001があります。オフセット0x5Cの値0x00000002は、このアレイに2人の参加者がいることを示しています。 オフセット0x80では、配列のデータ領域が0x00000800（2048）セクターから始まることが報告されています（カウントはスーパーブロックのあるセクションの先頭からです）。 オフセット0x88では、このセクションでRAIDアレイに参加するセクターの数0x000000015D3C932C（5 859 218 220）がQWORDに登録されます。



データの先頭の領域に移動すると、 LVM記号が見つかります





図 5



構成の最新バージョンに移動します。





図 6



構成では、このアレイ上に、「FILESHARE」という名前の1つのセグメントで構成される1つのボリュームがあり、アレイの容量全体をほぼ占有しています（エクステントの数*エクステントサイズ=セクターの容量715 206 * 8 192 = 5 858 967 552。このボリュームで説明するセクションには、Ext4ファイルシステムがあり、セクション名が内容と一致することを明確に示すエントリがあります。



2番目の3TBドライブの内容を分析すると、RAID 1のデータ領域に同一の構造が存在し、完全に準拠していることがわかります。これにより、このドライブもこのアレイの一部であることがわかります。 FILESHAREという名前のファイルホスティングサービスがユーザーに利用可能であることがわかっているため、これらの2つのディスクを今後の検討から除外します。



4TBドライブの分析に移ります。 これを行うには、保護パーティションテーブルの存在について各ドライブのゼロセクターの内容を考慮します。





図 7



しかし、代わりに、パーティションテーブルであると主張できないガベージコンテンツを見つけます。 1から33セクターの同様の図。 パーティションテーブル（保護MBR ）およびGPTの機能は、すべてのディスクに存在するわけではありません。 上記のRAID 1の分析では、このNASが公式目的のために割り当てる領域に関する情報を受け取りました。これに基づいて、ユーザーデータを含む別のアレイに参加している領域のセクションをオフセットできると仮定します。



オフセット0x28000000の近くにあるこれらのドライブで、RAIDスーパーブロック（正規表現0xFC 0x4E 0x2B 0xA9）を検索してみましょう。 各ディスクには、オフセット0x28101000にスーパーブロックがあります（アドレスは、ディスクの最初のペアのアドレスとわずかに異なります。おそらく、この場合、512バイトセクターのエミュレーションで4096バイトの物理セクターを持つ4TBディスクが考慮されたためです） 。





図 8



オフセット0x48、値0x00000005（RAID5）



オフセット0x58では、値0x00000400（1024）は、1024セクター（512KB）のストライピングユニットのサイズです。



オフセット0x5Cでは、値0x00000003は配列内の参加者の数です。 同じスーパーブロックを持つ4つのディスクがあり、記録によると3つのディスクが関係していることを考えると、ディスクの1つにホットスペアディスクの役割が割り当てられていると結論付けることができます。 また、このアレイがRAID 5Eであることも明確にしています。



オフセット0x80では、値0x0000000000000800（2048）は、セクションの先頭から配列に含まれる領域までのセクター数です。



オフセット0x88では、セクターの値0x00000001D1ACAE8F（7 812 722 319）は、配列に参加している領域のサイズです。



ホットスワップディスクとして使用されるドライブが動作を開始せず、再構築動作が実行されなかった場合、その内容は他の3つのディスクの内容とは大きく異なります。 この場合、16進エディターでディスクをスクロールすると、ほとんど空のドライブが簡単に検出されます。 また、彼らの考慮によって除外されます。



RAIDスーパーブロックがパーティションの先頭から標準オフセットにあると仮定すると、パーティションの先頭のアドレス0x28101000-0x1000 = 0x208100000を取得できます。 したがって、オフセットのコンテンツを考慮に入れた、データの先頭の領域：

0x208100000 +（0x0000000000000800 * 0x200）= 0x208200000。



このオフセットを調べてみると、各ディスク上の1024（0x800）セクターでは、LVMやその他の論理マーキングのバリエーションとは何も見つからないことがわかります。 3つのドライブの内容に対するXOR操作によってオフセット0x208200000でデータ検証テストを実行すると、安定して0が得られます。これはRAID 5の整合性を示し、1つのドライブがアレイから除外されていないことを確認します（再構築操作は実行されませんでした）。 RAID 1アレイの内容に基づいて、RAID 5アレイでは、最初に0x100000の領域（現在ガーベッジデータで満たされている）がLVMを収容するためのものであったと仮定します。



このRAIDはパリティブロックを備えた交互配列であり、配列の先頭から0x100000にバックトラックすることを考慮すると、各ディスクの位置0x208280000に移動する必要があります。おそらく、LVMのデータ領域はこのアドレスから始まります。 このバイアスのデータを分析して、この仮定を検証します。 これがスワップに使用されるボリュームではない場合、LVMで説明されているセクション内に何らかの論理マークアップの兆候、または何らかの種類のファイルシステムの兆候があるはずです。





図 9



ディスクの1つにある特性オフセット0x0400（クライアントの番号付け-No. 2による）により、Ext4スーパーブロックが見つかります。 その中で、オフセット0x04でのDWORDは、特定のファイルシステム内のブロック数であり、オフセット0x18で、ブロックサイズが暗黙的に指定されます（ブロックサイズを計算するには、2のべき乗（10 + X）、Xはオフセット0x18の値です）。 これらの値に基づいて、特定のファイルシステムが動作するパーティションのサイズを計算します0x00780000 * 0x1000 = 0x780000000バイト（30GB）。 パーティションのサイズは、アレイの容量よりもかなり小さいことがわかります。 これはLVMで説明されたセクションの1つにすぎないと考えており、配列の先頭からのオフセットに基づいて、ゼロ範囲で始まったと仮定できます。



データの場所に関する最初の仮定は正しいことが判明しましたが、RAID構成のスーパーブロックからの情報を使用してアレイを構築することはしませんが、パーティション内のデータを分析し、これに基づいてアレイパラメーターを設定します。 この方法により、このアレイのRAID構成のスーパーブロック内のパラメーターの正確さを確認したり、正しいパラメーターに反論して確立したりできます。



単調に増加するシーケンスを使用して、ブロックサイズとパリティブロックの交互パラメーターを決定すると便利です。 Ext2、Ext 3、Ext 4セクションでは、それらはグループ記述子にあります（すべての場合ではありません）。 各ドライブの便利な領域を見てみましょう。





図 10（HDD 2）





図 11（HDD 1）





図 12（HDD 0）



0x1000のステップで16進エディターで各ディスクをスクロールすると、セクター内オフセットでの数値の増加が0x00、0x04、0x08などであることに注意してください。 1024セクターまたは0x80000バイト（XOR演算結果のブロックではなく、データブロックでのみ有効）で実行され、RAIDスーパーブロックに記述されたブロックサイズを非常に明確に確認します。



写真を見て。 10、図 11、図 12、特定の場所でのディスクの役割とその使用順序を簡単に決定できます。 完全なマトリックスを構築するには、すべてのディスクのイメージを0x80000の増分でスクロールし、テーブルのオフセット0x00に値を入力します。 ディスク使用量テーブルに記入するために、最初のテーブルに入力した増加する値に従ってディスク名を入力します。





図 13



ディスク使用マトリックスに従って、最初の30 GB以内に0x28280000のRAID 5アレイを収集します。 このアドレスは、LVMの欠如と、発見したEXT4パーティションの先頭がこのオフセットに該当するという事実に基づいて選択されました。 結果の画像では、ファイルシステムと、そこに記述されているファイルタイプと実際に投稿されたデータとの対応を完全に確認できます。 私たちの場合、このチェックは欠陥を明らかにせず、以前のすべての結論の正確性を確認しました。 これで、配列の完全なコレクションを開始できます。



LVMがないため、アセンブルされたアレイ内のパーティションを見つける必要があります。 1つのセグメントで構成されるパーティションの場合、この手順は、クリーンなパーティションテーブル（MBR）またはGPTを使用して通常のドライブでパーティションを検索する場合と変わりません。 すべては、さまざまなファイルシステムとパーティションテーブルのパーティションの始まりの兆候を見つけることです。

失われたLVMに属し、2つ以上のフラグメントで構成されるボリュームの場合、追加の測定セットが必要になります。



-パーティション上のボリュームが占有するセクターの範囲を記録することにより、1つのセグメントで構成される論理ボリュームのマップを構築します。



-断片化されたボリュームの最初のセグメントのパーティションマップを構築します。 ブレークセクションの位置を正確に決定する必要があります。 失われたLVMで使用されている正確なエクステントサイズがわかっている場合、この手順ははるかに簡単です。 エクステントサイズの順序は、ボリュームの開始位置に基づいて想定できます。 残念ながら、この手法は常に適用できるとは限りません。





図 14



マップの空のセクションでは、断片化されたボリュームの最初のセグメントに増分する必要があるセグメントを検索する必要があります。 ボリュームのこのような断片が多数存在する可能性があることに注意してください。 一致する実際のデータを使用して、ボリュームのファイルシステム内のファイルレコードを分析することにより、増分の正確性を確認できます。



複雑な対策をすべて完了すると、RAIDアレイにあった論理ボリュームのすべてのイメージを取得できます。



また、この出版物では、データ回復のための専門的なシステムについて意図的に言及していないため、作業のいくつかの段階が簡素化されているという事実にも注意を促します。



次の投稿：SK6211コントローラーのUSBフラッシュのリバースエンジニアリング

前の投稿：暗号化トロイの木馬後のファイルの復元