☰

フルディスクで構築されたmdadm raid1の復元（パーティションデータの上書き）

tag-icon • tag-icon data-recovery raid luks mdadm raid1
フルディスクで構築されたmdadm raid1の復元（パーティションデータの上書き）

新しいPCを設定するとき、上部にLUKSがある2つのドライブを持つ新しいRAID 1も設定しました。すべてのデータをコピーしたら、すべてが利用可能であることを確認し、既存のドライブを破砕しました。

しかし、今ではRAIDはありません。 RAIDを作成するときにパーティションを使用する代わりにディスク全体を使用したため、これが最も可能性が高いことがわかりました。 RAIDを復元してその中のデータを回復する方法はありますか？ RAIDを生成するための正確なコマンドを保存しましたが、不可逆的な問題が発生しないと確信するまでは何もしたくありません。

fdisk -l両方のドライバの出力：

Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EFAX-68J
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 068E27EE-055B-A24A-B51B-D0B79E3DEA00

Disk /dev/sdc: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors
Disk model: TOSHIBA HDWD130 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F4ADCB83-B715-9B4A-A6A0-96687568611E

RAIDは、次のコマンドを使用して作成されます。

sudo mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc

mdadm --examine両方のディスクの出力は同じです。

/dev/sdb:
   MBR Magic : aa55
Partition[0] :   4294967295 sectors at            1 (type ee)

/dev/sdc:
   MBR Magic : aa55
Partition[0] :   4294967295 sectors at            1 (type ee)

したがって、パーティションデータは削除されたように見えるため、RAIDメンバーとして表示されなくなります（fdタイプ）。パーティションデータを書き換えてRAIDを再起動できますか？

私の行mdadm.confは次のとおりです。

ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=WORKSTATION:0 UUID=fe2547a6:3296c156:303989ac:febb5051 devices=/dev/sdb,/dev/sdc

メンバーが1人だけのRAIDを起動し、そのようにデータを回復できますか？ LUKSヘッダーは両方のディスクで同じでなければなりません。そうですか？それとも、上書きする前にバックアップする必要がありますか？

助けてくれて本当にありがとうございます。この問題が発生する前に、約1500 GBのデータがありました。

PS 2つのディスクがサイズが異なることを知っています。以前は2つの3TBドライブでしたが、そのうちの1つが故障して4TBドライブに交換しました。これが起こる前に、RAIDが動作し、完全に同期していました。

ベストアンサー1

RAID 1はシンプルミラーなので、RAIDの問題を無視してLUKSヘッダを直接取得できます。関連パーティションがない場合は、ドライブの先頭に近い必要があります。mdadmかなり大きなデータオフセットが使用されるため、おそらく数百MiBオフセットがある可能性があります。

次のコマンドは、ドライブの最初の1GiBを検索します。

# hexdump -C -n 1G /dev/sdx | grep LUKS
08100000  4c 55 4b 53 ba be 00 02  00 00 00 00 00 00 40 00  |LUKS..........@.|

この例では、オフセット0x8100000（129MiB）に潜在的なLUKSヘッダーがあります。

このオフセットで（読み取り専用）ループデバイスを作成して機能していることを確認してください。

# losetup --find --show --read-only --offset $((0x8100000)) /dev/sdx
/dev/loop2
# cryptsetup luksOpen /dev/loop2 lukstest
Enter passphrase:
# mount -o loop,ro /dev/mapper/lukstest /mnt/somewhere

機能している場合は、データをそのまま維持しながら回復を試みることができます。しかし、とにかく最初にフルバックアップコピーを作成することをお勧めします。

パーティションデータを書き換えてRAIDを再起動できますか？

理論的には必ず

  1. オフセット1MiB（将来のパーティションオフセット）を使用して2つのループデバイス（*）を作成します。
  2. ループデバイスで上記のhexdumpコマンドを再度実行して、正しいオフセットを確認します（ベアドライブと比較して-1MiBである必要があります）。
  3. これらの循環装置を使用して正しいオフセットでRAIDを再生成します。それに応じてmdadm.confを調整します。
  4. cryptsetup open急襲、
  5. ディスクの末尾にGPTバックアップヘッダー用のスペースを確保するために、ファイルシステムを少し減らしてください。
  6. ファイルシステムのマウント解除（マウントされている場合）、cryptsetup closeluks、mdadm --stopraid、losetup -dループデバイスの取り外し、
  7. 両方のドライブでオフセットが1MiBのパーティションを作成します。

この時点で、パーティションがあるドライブ、パーティションにRAID、RAIDにLuk、Luk内にファイルシステムが必要です。

ただし、これは最善のシナリオであり、あなたの状況を正しく理解した場合にのみこの方法で機能します。これが完全に間違っている可能性がある方法はいくつかあります。

(*)

デバイスの端を傷つけずにパーティションを作成するには、まずファイルシステムを縮小する必要があるため、ループデバイスを使用したジャンプリングが必要です。そして、RAIDが実行されている場合にのみファイルシステムを縮小することができます（2つのドライブで実行していて一貫性を維持する必要がある場合）。

パーティションを直接作成した場合、おそらく何も起こらなかったでしょう（またはとにかくそのようなことが起こったでしょう）。ただし、技術的には、この場合、RAWディスクからパーティションに移動する正しい方法ではありません。

おすすめ記事