☰

再起動後にLVMを含むベアメタルRAIDアレイが消える

tag-icon • tag-icon lvm raid mdadm software-raid
再起動後にLVMを含むベアメタルRAIDアレイが消える

簡単に言うと：

再起動すると、RAIDアレイ+ LVMが消えます。

詳細

以下に基づいて暗号化されたRAIDアレイを構築したいと思います。これは理由。

RAIDアレイを設定しました「ベアメタル」（つまり、パーティションではなくディスク上にある）アレイが構築された後、フォーマットせずに実行されましたpvcreate。その後、一般的な方法でLVMと暗号化を設定しました。 （望むよりデジタルオーシャンRAIDガイド、RAIDのLVMのアーキテクチャガイドライン。

暗号化設定後に実行しmdadm --detail --scan | tee -a /etc/mdadm/mdadm.confてupdate-initramfs -u再起動しました。/dev/md0それから消えた。私は何が間違っていましたか？

デバッグステップ。

似たような質問がたくさんありますが、これが私が読んだ内容に基づいてこれまで試しました。

  • 出力がmdadm --examine --scan空です。
  • コメントされていないコンテンツ/etc/mdadm/mdadm.conf：HOMEHOST <system>、、、、一部のSO回答で提案された重複エントリはありませんMAILADDR root。ARRAY /dev/md0 metadata=1.2 name=server:0 UUID=xxxxx
  • 発行service mdadm status利回りLoaded: masked (Reason: Unit mdadm.service is masked.)
  • 発行cat /proc/mdstat利回りPersonalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] \n unused devices: <none>
  • 私は走ろうとし、dpkg-reconfigure mdadmアドバイスupdate-initramfs -uに従った。ここ「すべて」を有効にするオプションが見つかりません。その後、再起動しようとしましたが、やはり動作しません。

最後の手段として私はそれを試しましたmdadm --assemble --scan。

奇妙なことに、このタイプはTYPE="linux_raid_member"私の期待に合わないこれは理由

root@server:/home/user# blkid
/dev/sda1: UUID="xx" TYPE="ext2" PARTUUID="xx-xx"
/dev/sda5: UUID="xx" TYPE="LVM2_member" PARTUUID="xx-xx"
/dev/mapper/server--vg-root: UUID="xx" TYPE="ext4"
/dev/mapper/server--vg-swap_1: UUID="xx" TYPE="swap"
/dev/sdb: PTUUID="xx" PTTYPE="gpt"
/dev/sdc: PTUUID="xx" PTTYPE="gpt"
/dev/sdd: PTUUID="xx" PTTYPE="gpt"

この配列はsd [bcd]にあり、/ dev / sdaはルートファイルシステムを保持します。このアレイドライブはデータに使用されます。

作り直すステップ。

完全性と場合に備えて便利です。

  • mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sdb /dev/sdc /dev/sdd配列の作成
  • pvcreate /dev/md0物理ボリュームの作成
  • vgcreate data_group /dev/md0ボリュームグループの作成
  • lvcreate -n secure data_group -L +900Gボリュームの作成
  • cryptsetup -v luksFormat /dev/data_group/secure暗号化設定
  • cryptsetup luksOpen /dev/data_group/secure cryptvault暗号化されたボリュームを開く
  • mkfs.ext4 /dev/mapper/cryptvault分割
  • mkdir /mnt/vaultマウントポイントの作成
  • mount /dev/mapper/cryptvault /mnt/vault山
  • mdadm --detail --scan | tee -a /etc/mdadm/mdadm.conf配列レイアウトの保存
  • update-initramfs -u新しい設定でinitを更新
  • reboot

答え1

これは単なる理論です。mdadmメタデータバージョン1.2はデバイス起動から4K離れており、アレイを作成するときにディスクにすでに既存のGPTパーティションテーブルがあります。これはmdadmによって削除されませんでした（mdadmは既存の署名をすべて削除すると予想しましたが、署名の存在に関するGPTの説明）。すべてのツール（mdadmを含む）では、これはmdmemberの代わりにGPTパーティションテーブルを持つ空のディスクのように見えるため（blkidがディスクの末尾近くのヘッダーバックアップを検出する可能性があるため）、配列はアセンブルされません。無視する。

wipefs試してみることができます。まずwipefs /dev/sdb、すべての署名を検出して印刷し、wipefs -o <offset>前のコマンドで印刷されたGPT署名のオフセットを使用してパーティションテーブルを削除します。これは、システムがディスクをmdmeberデバイスとして検出するのに役立ちます。

それでも役に立たない場合は、最初から再起動してメタデータバージョン1.1（--metadata=1.1mdadmオプション、1.1ではメタデータをデバイスの先頭に配置）を選択するか、パーティション上にアレイを作成することをお勧めします（ディスクを使用する場合の利点はありません）。 ）IMHO、パーティションテーブルはありません）。または、他の人がより良い提案をするのを待つこともできます。 :-)

ところで。これはまったく新しい設定なので、デバイスに貴重なデータがないとします。ただし、元に戻すことができない変更を加える前に、ディスクの最初の数MiBをバックアップすると便利です。

関連情報