☰

raid5の問題が発生した後のraid5 + lvm reiserfsパーティションからのデータ復旧

tag-icon • tag-icon linux lvm data-recovery reiserfs
raid5の問題が発生した後のraid5 + lvm reiserfsパーティションからのデータ復旧

3つのSATAハードドライブを持つサーバーがあります。各パーティションには2つのパーティションがあります。小さい部分は raid1 配列 (/boot) の /dev/md0 の一部であり、残りは lvm 物理ボリューム raid5 配列 (/dev/md1) の一部です。その中には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全体をインストールすることをお勧めします。いいえこれらの小さなパーティションをミラーリングしますが、個別に完全に起動可能にします。

syncインストール中にいくつかの重要なファイル（/etc/fstab、grub設定）を除外できます。これにより、より多くのスペースが必要になるだけでなく、/boot問題が発生したときに多くの時間を節約できます。

答え2

以前と同じ順序でドライブを組み立てていない場合や、以前と同じブロックサイズを使用していない可能性があります。以前の順序が何であるかを判断し、配列を再作成するときは同じ順序を使用する必要があります。つまり、3番目のディスクが死んでいるのではなく、1番目または2番目のディスクがsdaとsdbを混同した可能性があります。

答え3

ように @プシュ市 ヒントメタデータ形式はkyeで、次のようになります。 「0.9」の代わりに「1.2」がデフォルトです。残念ながら、1.2では4KiBオフセットを使用しているため、データ損失が発生する可能性があります。

1、1.0、1.1、および1.2はデフォルトで新しいバージョン1フォーマットのスーパーブロックを使用します。これはあまり制限されていません。エンディアンは異なるホスト間で簡単に移動でき、回復操作を確認して再開できます。さまざまなサブバージョンは、デバイスの端（1.0の場合）、開始（1.1の場合）、または最初から4K（1.2の場合）など、デバイスの異なる場所にスーパーブロックを保存します。

1つのアドバイス（遅いですが）：- -Bbuildを使わずに配列を再生成しようと急いではいけません。

   -B, --build
          Build a legacy array without superblocks

UPD.:結果は-BRAID-5の構築を拒否します...:-/

関連情報