☰

ヘッダーが破損した新しいコンピュータのLuksボリュームはありますか？

tag-icon • tag-icon linux raid luks
ヘッダーが破損した新しいコンピュータのLuksボリュームはありますか？

raid1のLuksボリュームにデータをバックアップしました（raid 1の最初の2つのディスク、2番目のLuks）。

2台のドライブを新しいサーバーに移動すると、動作が停止しました。軽いパニック発作の後、私はより多くの情報を検索し、いくつかのウェブサイトではHexdumpを使用してヘッダーの内容を調べることを提案しました。しかし、多くのウェブサイトでは、それがどこにあるのかわかりません。自分のデータを回復できるのか、何が起こったのかを教えてくれる人はいますか？

私がしたことは、それらを新しいコンピュータに移動するだけでした。インストールは必要ありません。命令もなく、奇妙なこともありません。既存のオペレーティングシステムがインストールされているコンピュータを接続して起動します。

sudo hexdump -Cvs 0 -n 2000 /dev/sdb

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001c0  01 00 ee fe ff ff 01 00  00 00 ff ff ff ff 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  53 16 20 86 00 00 00 00  01 00 00 00 00 00 00 00  |S. .............|
00000220  af be c0 d1 01 00 00 00  00 08 00 00 00 00 00 00  |................|
00000230  8e be c0 d1 01 00 00 00  e1 8a 60 b4 82 6f 50 42  |..........`..oPB|
00000240  93 ea db 27 34 ec a7 5b  02 00 00 00 00 00 00 00  |...'4..[........|
00000250  80 00 00 00 80 00 00 00  86 d2 54 ab 00 00 00 00  |..........T.....|

次のコマンドを使用してRAIDが作成されました。 （ドライブ名に合わせて編集）

sudo mdadm --create --verbose /dev/md5 --level=1 --raid-devices=2 /dev/sdp /dev/sdb

lsblk は以下を示しています。

sdb                         8:16   0   3.7T  0 disk
sdp                         8:240   0   3.7T  0 disk

fdisk -l /dev/sdb

Disk /dev/sdb: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: EFRX-68WT0N0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B4608AE1-6F82-4250-93EA-DB2734ECA75B

また、明確にするために元のコンピュータに戻したが、それでも認識されません。 mdadm は攻撃隊のメンバーではないことを示します。でも

mdadm - アセンブリ - スキャン

何もしなかった

答え1

やろう！気づいた！

そのため、ハードドライブを新しいコンピュータに挿入したときに、何らかの方法で新しいマッピング/ブロックサイズを持つようになったかどうかはわかりません。

私は破産しました

sudo hexdump -s 0 -n 1000000000 -C /dev/sdb | grep LUKS

これにより、最初のGBでLUKSフレーズが検索されます。

結果:

08000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|

次に、そのオフセットのループバックを作成しました。

sudo losetup -o 0x08000000 -r -f /deb/sdb

今私のループバックを一覧表示すると、次のようになります。

sudo losetup -a
/dev/loop8: [0006]:659 (/dev/sdb), offset 134217728

今マウントを開き、指をねじってみましょう。

sudo cryptsetup luksOpen /dev/loop8 luksrecover

だから...開いてください！

一般的なインストールコマンドを入力してもう一度作業を開始してください。定義。このヘッダーをバックアップしてください。データをコピーしてドライブを再フォーマットして再挿入しても、なぜこれが起こるのかわかりません。

答え2

16進ダンプには、ブロック＃0（00000000 - 000001ff）とブロック＃1の先頭（00000200+）が表示されます。

000001feでは、値は0xaa55（リトルエンディアン）です。ブロック＃0の内容は、MBRパーティションテーブルが存在するというデフォルトの表示です。最初の（この場合は唯一の）デフォルトのパーティション項目は000001be - 000001cdにあります。つまり：

000001b0  .. .. .. .. .. .. .. ..  .. .. .. .. .. .. 00 00  |................|
000001c0  01 00 ee fe ff ff 01 00  00 00 ff ff ff ff .. ..  |................|

これ次のようにデコードされます。0xee タイプの非アクティブパーティションは LBA 0x00000001 で始まり、長さは 0xffffffff です。これはCHSフィールドが表すことができるよりも大きいため、パーティションの開始/終了CHSフィールドは無視できます。

パーティションタイプは、0xeeこれがGPTであることを示します。保護MBRしたがって、このMBRパーティションテーブルは完全に無視する必要があります。実際のGPTパーティションテーブルLBA＃1から始めてください。

first usable LBA16進ダンプの00000228で始まる値が0x00000000 00000800のGPTヘッダーフィールドはブロック2048です。ここに512バイトのブロックサイズを掛けると、1MiBディスクの一般的な値である0x100000または1048576になります。これは見つかったオフセット（134217728 = ディスクの128MiB）と一致しないため、LUKSパーティションの前にディスクにLUKS以外のパーティションがある可能性があります。残念ながら、GPTパーティションエントリはブロック＃2以降のブロック（必要な場合）に格納されるため、16進ダンプでは検証を許可しません。

GPTヘッダーのフィールドlast usable LBA値は0x01d1c0be8e = 7814037134で、ダンプのオフセット00000230にあります。これは報告されたディスクサイズよりも34ブロック小さいものでfdisk、これは正しいようです。ディスクの末尾には、バックアップGPTヘッダブロック用の33ブロックと32個のパーティションエントリブロック用のスペースがあります。 +1はブロック番号がブロックから削除された＃1ではなく＃0で始まります。

これにより、RAIDメタデータ領域用のパーティションスペースの外にスペースが残らないようです。

RAIDがパーティションデバイスではなくディスクデバイス全体を使用して作成されたと確信していますか？つまり、こんなことかもしれません。

sudo mdadm --create --verbose /dev/md5 --level=1 --raid-devices=2 /dev/sdp2 /dev/sdb2

代わりに：

sudo mdadm --create --verbose /dev/md5 --level=1 --raid-devices=2 /dev/sdp /dev/sdb

RAIDアレイの作成後にfdisk /dev/sdb同様のものをfdisk /dev/sdp使用してディスクを分割すると、GPTパーティションテーブルはRAIDメタデータを上書きし、再起動後にRAIDがなくなり、通常のGPTがディスクを分割します。 （2番目のディスクは現在使用されておらず、まもなく最初のディスクと同期されません。）

もう一つの可能​​性はファームウェアがRAIDメタデータを消去した可能性があります。（またはここ）、古いシステムに戻るとき、またはディスクを新しいシステムに移動するとき。

デフォルトでは、システムのUEFIファームウェアはLinuxソフトウェアRAIDを理解していませんが、GPTパーティションテーブルを確実に理解しています。ファームウェアがディスクの先頭にGPTデフォルトパーティションテーブルがあることがわかりましたが、バックアップパーティションテーブルがディスクの最後に正しく表示されない場合（RAIDメタデータがメタデータ形式1.0以下で保存されているため）、一部のUEFIファームウェアはlast usable LBAバックアップGPTをディスクの実際の端に書き直して、RAIDメタデータを上書きするようにデフォルトのGPTを増やしてこの問題を「修正」します。

この「修正」は明らかにUEFIファームウェアの問題です。しなければならないUEFIの仕様に従ってこれを行います。 LUNのサイズ変更は、エンタープライズSAN管理者にとっては便利ですが、ディスク全体のRAID実装には面倒です。

同様に、ソフトウェアRAIDメタデータフォーマット1.1以降（RAIDメタデータをディスクの先頭に配置）を使用している場合、ファームウェアはバックアップGPTそして、それを使って「失われた」マスターGPTを再構築し、...再びRAIDメタデータを踏みます。

フルディスクレベル機能ソフトウェアRAIDがある場合とRAID内のパーティションその後、暗号化されたLUKSボリュームは〜しなければならないすでにまたは/dev/md/d5p2のようなものです/dev/md_d5p2。

現在、デフォルトのGPT以降、最初のパーティションが開始される前に未割り当て領域がある場合、これはRAIDメタデータフォーマット1.1以降を使用しており、ファームウェアがRAIDメタデータ以降のデフォルトGPTを変更していることを意味できます。ディスクの真の始まり。

同様に、ディスクがかつてパーティションによって完全に占有されていましたが、最後のパーティション以降に約64-128Kの未割り当て領域がある場合は、RAIDメタデータ形式1.0以下を使用しており、ファームウェアはそれを上書きしました。両方でバックアップGPTを使用します。元のシステムとディスクを新しいシステムに移動するとき。

私の考えでは、GPTはソフトウェアRAIDセットを構築する人なら誰でも知る必要がある新しいものを提供します。

  • （ペアリングされた）パーティションからパーティション化されていないRAIDセットを作成するのに問題はないようです（つまり、次のよう/dev/md0に作成および作成など）。/dev/sdX1/dev/sdY1/dev/md1/dev/sdX2/dev/sdY2
  • sgdisk --zapフルディスクソフトウェアRAID設定を準備するときは、ファームウェアベースの自動回復が次回の起動時にRAIDメタデータをすぐに上書きしないようにするために、同様のツールを使用してプライマリおよびバックアップGPTを完全に消去するように注意する必要があります。
  • UEFIシステムでディスク全体のRAIDを細分化するとき、ファームウェアはRAID内のGPTを検出できるため、GPTパーティション以外のパーティションを次の上位層として使用することをお勧めします（フルディスクRAIDアレイデバイスをLVM PVにすることもできます。 ）。 RAID層を理解していないまま、「誤って配置された」GPTを「修正」しようとすると、コンテナパーティションテーブルが破損し、RAIDメタデータが破損しました。
  • 言い換えれば、UEFI ブート可能なシステムディスクで完全なディスクソフトウェアRAIDを使用することはおそらく良い考えではありません。システムディスクにはデフォルトでGPTパーティションテーブルとEFIシステムパーティションが必要で、ファームウェアは両方を完全にサポートできる必要があるためです。パーティション。調べて訪問してみてください。

関連情報