3 台の SATA ハード ドライブを備えたサーバーがあります。各サーバーには 2 つのパーティションがあります。1 つは小さいパーティションで、raid1 アレイ (/boot) の /dev/md0 の一部です。残りは raid5 アレイ (/dev/md1) の一部で、lvm 物理ボリュームです。内部には 3 つの (IIRC) 論理ボリュームがあります。そのうちの 1 つは、約 100 GB のデータを保持する reiserfs 3.6 fs です。
昨日、このサーバーがクラッシュしました。電源を入れると、SMART がドライブの 1 つが故障していると表示しました。確かに、非常にひどい音がしていました。そこで、故障したドライブを取り外し、残りの 2 つのディスクでシステムを再起動しようとしましたが、失敗しました。
ライブ CD を使用して起動し、アレイを再起動しようとしました。残念ながら、mdadm は残りの 2 つのディスクのうちの 1 つにも障害が発生していると判断し、再起動を拒否しました。
そこで、次のアドバイスに従ってくださいクラッシュした Linux md RAID5 アレイを回復するにはどうすればいいですか?私の状況に当てはまるように見えたので、私はおそらく単純に愚かなことをしました。
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sd[ab]2 missing
現在、このアレイを実際に起動することはできますが、lvm ツール (vgscan、vgdisplay、pvck) はアレイ上の lvm に関連するものを何も見つけることができず、データにまったくアクセスできません。lvm メタデータをすべて消去したのでしょうか?
実際のデータはまだそこにあり、損傷を受けていないように思います (LVM メタデータを除く)。データを復元できる可能性はありますか? 方法は?
アップデート：
psusi さん (下記) のアドバイスに従って、配列を再作成する以下の各方法を試しました。
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 /dev/sdb2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 /dev/sda2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sda2 missing /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 /dev/sdb2 missing /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sda2 /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c64 missing /dev/sdb2 /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 /dev/sdb2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 /dev/sda2 missing
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sda2 missing /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 /dev/sdb2 missing /dev/sda2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sda2 /dev/sdb2
mdadm --create /dev/md1 --assume-clean -l5 -n3 -c512 missing /dev/sdb2 /dev/sda2
これは基本的に、-c64 と -c512 の両方で可能なすべての順序です。各テストの後、vgscan を実行しました。何も見つかりませんでした。vgscan ではなく、他のツールを使用する必要があるのでしょうか?
更新2:
故障したハードドライブを再接続してみました。奇跡的に、何とか機能しているようです。少なくとも、調べるには十分です。
root@debian:~# mdadm --examine /dev/sda2
/dev/sda2:
Magic : a92b4efc
Version : 0.90.00
UUID : 1f5462ab:6945560d:019b01a5:914dd464
Creation Time : Fri Oct 17 12:40:40 2008
Raid Level : raid5
Used Dev Size : 160015360 (152.60 GiB 163.86 GB)
Array Size : 320030720 (305.21 GiB 327.71 GB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 1
Update Time : Tue Apr 12 08:15:03 2011
State : active
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Checksum : 64d514fb - correct
Events : 137
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 0 8 2 0 active sync /dev/sda2
0 0 8 2 0 active sync /dev/sda2
1 1 8 18 1 active sync /dev/sdb2
2 2 8 34 2 active sync /dev/sdc2
では、このスーパーブロックを他の 2 つのデバイスにコピーして、アレイを「適切に」起動する方法はありますか?
答え1
私も同様の設定をしており、各ドライブの小さなパーティションに完全なLinuxをインストールすることをお勧めします。ないこれらの小さなパーティションをミラーリングしますが、個別に完全に起動できるようにします。
いくつかの重要なファイル ( 、grub 構成)syncを除外してセットアップできます。これにより、より多くのスペースが必要になりますが、問題が発生した場合に多くの時間を節約できます。/etc/fstab/boot
答え2
おそらく、ドライブを以前と同じ順序で組み立てなかったか、同じチャンク サイズを使用していなかったのでしょう。以前の順序を把握し、アレイを再作成するときに同じ順序を使用する必要があります。つまり、故障したのは 3 番目のディスクではなく、1 番目または 2 番目のディスクである可能性があり、sda と sdb を混同している可能性があります。
答え3
として @プシ ほのめかしたメタデータ形式は、どうやら kye のようです。現在、デフォルトは「0.9」ではなく「1.2」です。残念ですが、1.2 は 4 KiB のオフセットを使用するため、データ損失につながる可能性があります。
1、1.0、1.1、1.2 デフォルト 新しいバージョン 1 形式のスーパーブロックを使用します。この形式は制限が少なくなっています。異なるエンディアンを持つホスト間で簡単に移動でき、リカバリ操作のチェックポイントを作成して再開できます。異なるサブバージョンでは、スーパーブロックがデバイスの異なる場所 (末尾 (1.0 の場合)、先頭 (1.1 の場合)、または先頭から 4K (1.2 の場合)) に保存されます。
アドバイス（残念ながら遅いですが）：次の方法で試さずに、配列の再作成を急がないでください-B。
-B, --build Build a legacy array without superblocks
上院.: -BRAID-5 の構築を拒否することが判明しました… :-/