再利用するのではなく、新しいアレイを作成した後にRAID 5データを回復する
人々は助けてください-私は手元に大きな頭痛の種を持っている新米です（完璧な嵐の状況）。
ソフトウェアレイド5として構成されたubuntu 11.04に3つの1 TB HDDがありました。データは、完全に失敗して破棄されるまで、コンピュータのハードドライブから別の別のドライブに毎週コピーされていました。数日前に停電が発生し、再起動後、ボックスはレイドをマウントしなくなりました。私の無限の知恵に私は入りました
mdadm --create -f...
代わりにコマンド
mdadm --assemble
そして、私がしたことまでの奇行に気づきました。アレイの劣化が始まり、構築と同期が進行しました。これには約10時間かかりました。私が戻った後、アレイは正常に稼働しているが、レイドはそうではないことがわかりました
つまり、個々のドライブはパーティション分割されていますが（パーティションタイプf8）、md0デバイスはパーティション分割されていません。私が何をしたかを恐怖の中で悟り、いくつかの解決策を見つけようとしています。 --createがハードドライバーのコンテンツ全体を上書きしないことを祈ります。
誰かがこれで私を助けてくださいませんか-ドライブにあるデータは非常に重要でユニークです〜10年の写真、ドキュメントなど.
参加しているハードドライブを間違った順序で指定すると、mdadmによって上書きされる可能性がありますか？私がする時
mdadm --examine --scan
ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0のようなものが表示されます
興味深いことに、十分な名前は「raid」であり、：0が追加されたHost hameではありませんでした。
これが「無害化された」構成エントリです。
DEVICE /dev/sdf1 /dev/sde1 /dev/sdd1
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST <system>
MAILADDR root
ARRAY /dev/md0 metadata=1.2 name=tanserv:0 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b
Here is the output from mdstat
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[0] sdf1[3] sde1[1]
1953517568 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
fdisk shows the following:
fdisk -l
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bf62e
Device Boot Start End Blocks Id System
/dev/sda1 * 1 9443 75846656 83 Linux
/dev/sda2 9443 9730 2301953 5 Extended
/dev/sda5 9443 9730 2301952 82 Linux swap / Solaris
Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000de8dd
Device Boot Start End Blocks Id System
/dev/sdb1 1 91201 732572001 8e Linux LVM
Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00056a17
Device Boot Start End Blocks Id System
/dev/sdc1 1 60801 488384001 8e Linux LVM
Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ca948
Device Boot Start End Blocks Id System
/dev/sdd1 1 121601 976760001 fd Linux raid autodetect
Disk /dev/dm-0: 1250.3 GB, 1250254913536 bytes
255 heads, 63 sectors/track, 152001 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/dm-0 doesn't contain a valid partition table
Disk /dev/sde: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x93a66687
Device Boot Start End Blocks Id System
/dev/sde1 1 121601 976760001 fd Linux raid autodetect
Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe6edc059
Device Boot Start End Blocks Id System
/dev/sdf1 1 121601 976760001 fd Linux raid autodetect
Disk /dev/md0: 2000.4 GB, 2000401989632 bytes
2 heads, 4 sectors/track, 488379392 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000
Disk /dev/md0 doesn't contain a valid partition table
提案に従って、スーパーブロックをクリーンアップし、--assume-cleanオプションを使用して配列を再作成しましたが、まったく運がありませんでした。
少なくとも一部のデータを復活させるのに役立つツールはありますか？誰かがmdadm --createが同期時にデータを破棄するために何をどのように行うのか教えてくれますか？
RAIDを再作成した後、私はfsck.ext4/dev/md0を実行し、ここに出力があります
root @ tanserv：/ etc/mdadm＃fsck.ext4/dev/md0 e2fsck 1.41.14（22-Dec-2010）fsck.ext4：スーパーブロックが無効、バックアップブロックを試行中... fsck.ext4：スーパーの不正なマジック番号/ dev/md0を開こうとするときにブロックする
スーパーブロックを読み取ることができなかったか、正しいext2ファイルシステムを記述していません。デバイスが有効で、実際にext2ファイルシステムが含まれている（スワップやufsなどではない）場合、スーパーブロックが破損しているため、代替のスーパーブロックを使用してe2fsckを実行してみます。e2fsck -b 8193
私が試したシェーンズの提案による
root@tanserv:/home/mushegh# mkfs.ext4 -n /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=256 blocks
122101760 inodes, 488379392 blocks
24418969 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
14905 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
そして、すべてのバックアップブロックでfsck.ext4を実行しますが、すべてが以下を返しました。
root@tanserv:/home/mushegh# fsck.ext4 -b 214990848 /dev/md0
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Invalid argument while trying to open /dev/md0
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
助言がありますか？
よろしく！
わかりました-あなたの問題について何か問題があったので、VMを起動して予想される動作に飛び込みました。問題の原因を1分で確認します。最初に私はこれを言う：
何かを試みる前にこれらのドライブをバックアップしてください!!
再同期が行った以上のダメージをすでに与えている可能性があります。あなたが言ったときにあなたが何を意味していたのかを明確にできますか：
提案に従って、スーパーブロックをクリーンアップし、--assume-cleanオプションを使用して配列を再作成しましたが、まったく運がありませんでした。
mdadm --misc --zero-superblockを実行した場合は、問題ありません。
とにかく、いくつかの新しいディスクを清掃して、これらのディスクに書き込みを行う可能性のある操作を行う前に、それらの現在のイメージを正確に取得します。
dd if=/dev/sdd of=/path/to/store/sdd.img
そうは言っても..これらのものに保存されているデータは、わずらわしい再同期に対して衝撃的に回復力があるようです。読み進めてください。希望があり、これが回答の長さの制限に達した日かもしれません。
最良のシナリオ
VM=シナリオを再作成するために一緒に投げました。ドライブは100 MBしかないので、再同期するたびに永遠に待機することはありませんが、それ以外の場合はかなり正確な表現になるはずです。
可能な限り一般的でデフォルトのアレイを構築-512kチャンク、左対称レイアウト、文字順のディスク..特別なことは何もありません。
root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
ここまでは順調ですね;ファイルシステムを作成し、それにデータを入れましょう。
root@test:~# mkfs.ext4 /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=512 blocks, Stripe width=1024 blocks
51000 inodes, 203776 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
root@test:~# mkdir /mnt/raid5
root@test:~# mount /dev/md0 /mnt/raid5
root@test:~# echo "data" > /mnt/raid5/datafile
root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
OK。ファイルシステムといくつかのデータ（datafileの「データ」、およびrandomdataのそのSHA1ハッシュを使用した5MB相当のランダムデータ）があります。再作成するとどうなるか見てみましょう。
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[2] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
再同期はこれらの小さなディスクで非常に迅速に終了しましたが、実際に発生しました。だからここに私が以前から私を悩ませていたものがあります。 fdisk -l出力。 mdデバイスにパーティションテーブルがないことはまったく問題ではありませんが、予想されます。ファイルシステムは、パーティションテーブルのない偽のブロックデバイスに直接存在します。
root@test:~# fdisk -l
...
Disk /dev/md1: 208 MB, 208666624 bytes
2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000
Disk /dev/md1 doesn't contain a valid partition table
ええ、パーティションテーブルはありません。だが...
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
再同期後の完全に有効なファイルシステム。いいですね。データファイルを確認してみましょう。
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
しっかり-データの破損はまったくありません！ただし、これはまったく同じ設定であるため、2つのRAIDグループ間で異なってマッピングされたものはありません。それを壊そうとする前に、これを落としましょう。
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
一歩後退
これを壊す前に、なぜ壊しにくいのかを話しましょう。 RAID 5は、アレイ内の他のすべてのディスク上のブロックと同じサイズの領域を保護するパリティブロックを使用して機能します。パリティは特定の1つのディスクだけにあるのではなく、通常の操作でディスク全体に読み取り負荷を分散するために、ディスクを中心に均等にローテーションされます。
パリティを計算するXOR演算は次のようになります。
DISK1 DISK2 DISK3 DISK4 PARITY
1 0 1 1 = 1
0 0 1 1 = 0
1 1 1 1 = 0
したがって、パリティはディスク間で分散されます。
DISK1 DISK2 DISK3 DISK4 DISK5
DATA DATA DATA DATA PARITY
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
再同期は通常、無効なディスクまたは欠落しているディスクを交換するときに行われます。また、mdadm createで行われ、ディスク上のデータがRAIDのジオメトリが想定するものと一致することを保証します。その場合、アレイ仕様の最後のディスクは「同期」されるディスクです。他のディスク上の既存のデータはすべて同期に使用されます。
したがって、「新しい」ディスク上のすべてのデータは消去され、再構築されます。そこにあるはずのパリティブロックから新しいデータブロックを構築するか、新しいパリティブロックを構築します。
クールなのは、これら両方の手順がまったく同じであるということです。XOR残りのディスクのデータ全体の操作。この場合の再同期プロセスには、そのレイアウトに特定のブロックはパリティブロックである必要があり、実際に古いデータブロックを再作成しているときに、新しいパリティブロックを構築していると考えます。そのため、と考えてもこれを構築しています：
DISK1 DISK2 DISK3 DISK4 DISK5
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
DATA DATA PARITY DATA DATA
...上記のレイアウトからDISK5を再構築しているだけかもしれません。
そのため、配列が正しく構築されていなくても、データの整合性が保たれる可能性があります。
作品に猿を投げる
（レンチではなく、サル全体）
テスト1：
配列を間違った順序で作ってみましょう！ sdc、次にsdd、次にsdb ..
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
OK、それで問題ありません。ファイルシステムはありますか？
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
違う！何故ですか？データはすべて揃っていますが、順序が間違っているためです。かつては512KBのA、次に512KBのB、A、Bなどが、今度はB、A、B、Aにシャッフルされました。ディスクはファイルシステムチェッカーに対してジブライッシュに見え、実行されません。 mdadm --misc -D /dev/md1の出力は、詳細を示しています。次のようになります。
Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
3 8 17 2 active sync /dev/sdb1
次のようになるはずです。
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
3 8 49 2 active sync /dev/sdd1
ですから、それですべてうまくいきます。今回は、一連のデータブロックを新しいパリティブロックで上書きしました。正しい順序で今すぐ再作成します。
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
きちんと、まだファイルシステムがあります！まだデータがありますか？
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
成功！
テスト2
では、チャンクサイズを変更して、問題が発生するかどうか確認してみましょう。
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
ええ、そうです、このように設定するとホースが外れます。しかし、私たちは回復できますか？
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
再び成功しました！
テスト
これは確かにデータを殺すだろうと思ったものです-別のレイアウトアルゴリズムを実行しましょう！
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
怖いと悪い-それは何かを見つけたと考えており、いくつかの修正をしたい！ Ctrl+C！
Clear<y>? cancelled!
fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1
さて、危機は回避されました。間違ったレイアウトで再同期した後も、データがまだ変更されていないか確認してみましょう。
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
成功！
テスト4
また、スーパーブロックのゼロ化が実際に有害ではないことを証明しましょう。
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
ええ、大したことはありません。
テスト5
私たちが持っているすべてのものを捨てましょう。以前の4つのテストすべてを組み合わせたもの。
- デバイスの注文が間違っている
- チャンクサイズが間違っています
- 間違ったレイアウトアルゴリズム
- ゼロ化されたスーパーブロック（両方の作成の間にこれを行います）
先に！
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
評決？
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 13/51000 files, 17085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
ワオ。
したがって、これらのアクションのいずれも、データを破損することはありません。率直に言って、私はこの結果にかなり驚きました。チャンクサイズの変更によるデータ損失の確率は中程度であり、レイアウトの変更による一定の損失が予想されました。今日は何かを学びました。
だから..どのようにして私のデータを取得しますか？
古いシステムに関する情報と同じくらい多くの情報が非常に役立ちます。ファイルシステムタイプがわかっている場合、/proc/mdstatの古いコピーがあり、ドライブの順序、アルゴリズム、チャンクサイズ、メタデータバージョンに関する情報が含まれている場合。 mdadmのメール警告を設定していますか？もしそうなら、古いものを見つけてください。そうでない場合は、/var/spool/mail/rootを確認してください。 ~/.bash_historyをチェックして、元のビルドがそこにあるかどうかを確認します。
だから、あなたがすべきことのリスト：
- 何かをする前に
ddでディスクをバックアップしてください!! - 現在のアクティブなmdを
fsckしてみてください-たまたま、以前と同じ順序でビルドした可能性があります。ファイルシステムのタイプがわかっている場合は、それが役立ちます。その特定のfsckツールを使用します。いずれかのツールが何かを修正することを提案している場合、それらが実際に有効なファイルシステムを見つけたことが確実でない限り、それらを許可しないでください！fsckが何かを修正することを申し出た場合は、コメントを残して、それが実際に役立っているのか、それともデータを破壊しようとしているのかを尋ねてください。 - 異なるパラメーターで配列を作成してみてください。古い
/proc/mdstatを持っている場合は、それが示すものを真似ることができます。そうでない場合は、少し暗闇の中でです。さまざまなドライブの順序をすべて試すことは合理的ですが、可能なすべての順序ですべての可能なチャンクサイズをチェックすることは無駄です。それぞれについて、fsckを使用して、有望なものがあるかどうかを確認します。
それで、これで終わりです。小説でごめんなさい、質問があればコメントを残してください、そして幸運を！
脚注：22,000文字未満;長さ制限の8k +恥ずかしがり屋
私は同様の問題を抱えていました：
ソフトウェアRAID5アレイに障害が発生した後、mdadm --createを指定せずに--assume-cleanを起動しましたが、アレイをマウントできなくなりました。 2週間掘り進んだ後、ようやくすべてのデータを復元しました。以下の手順が誰かの時間を節約することを願っています。
ロングストーリーショート
この問題は、mdadm --createが2つの点で元の配列とは異なる新しい配列を作成したために発生しました。
- パーティションの順序が異なる
- 異なるRAIDデータオフセット
見事な Shane Maddenによる回答 で示されているように、mdadm --createはほとんどの場合データを破壊しません！パーティションの順序とデータオフセットを見つけた後、配列を復元し、そこからすべてのデータを抽出することができました。
前提条件
私はRAIDスーパーブロックのバックアップを持っていなかったので、Xubuntu 12.04.0のインストール中に作成された8つのパーティション上のRAID5アレイであることを知っていました。 ext4ファイルシステムがありました。もう1つの重要な知識は、RAIDアレイにも保存されているファイルのコピーでした。
ツール
Xubuntu 12.04.1ライブCDを使用してすべての作業を行いました。状況によっては、次のツールのいくつかが必要になる場合があります。
データオフセットを指定できるmdadmのバージョン
Sudo apt-get install binutils-dev git
git clone -b data_offset git://neil.brown.name/mdadm
cd mdadm
make
bgrep-バイナリデータの検索
curl -L 'https://github.com/tmbinc/bgrep/raw/master/bgrep.c' | gcc -O2 -x c -o bgrep -
hexdump、e2fsck、マウントおよび16進数計算機-リポジトリの標準ツール
完全バックアップから始める
デバイスファイルの命名（例： /dev/sda2/dev/sdb2などは永続的ではないため、ドライブのシリアル番号を書き留めておくことをお勧めします
Sudo hdparm -I /dev/sda
次に、外付けHDDを接続し、次のようにRAIDアレイのすべてのパーティションをバックアップします。
Sudo dd if=/dev/sda2 bs=4M | gzip > serial-number.gz
元のRAID5レイアウトを決定する
ここでは、さまざまなレイアウトについて説明します。 http://www.accs.com/p_and_p/RAID/LinuxRAID.html
元のアレイでデータのストリップがどのように編成されたかを見つけるには、アレイに格納されていることがわかっているランダムに見えるファイルのコピーが必要です。 mdadmが現在使用しているデフォルトのチャンクサイズは512KBです。 Nパーティションの配列の場合、少なくとも（N + 1）* 512KBのサイズのファイルが必要です。 jpegまたはビデオは、バイナリデータの比較的一意の部分文字列を提供するため、優れています。ファイルの名前がpicture.jpgであるとします。 100kから始まり、512kずつ増加する32バイトのデータをN + 1の位置で読み取ります。
hexdump -n32 -s100k -v -e '/1 "%02X"' picture.jpg ; echo
DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2
hexdump -n32 -s612k -v -e '/1 "%02X"' picture.jpg ; echo
AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7
hexdump -n32 -s1124k -v -e '/1 "%02X"' picture.jpg ; echo
BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA
...
次に、すべてのrawパーティションでこれらのすべてのバイト文字列の出現を検索します。つまり、次のように合計（N + 1）* Nコマンドです。
Sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sda2
Sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdb2
...
Sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdh2
/dev/sdh2: 52a7ff000
Sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/sda2
/dev/sdb2: 52a87f000
...
これらのコマンドは、異なるディスクに対して並行して実行できます。 38GBパーティションのスキャンには約12分かかりました。私の場合、すべての32バイト文字列は、8つのドライブすべてで1回だけ見つかりました。 bgrepから返されたオフセットを比較すると、次のような画像が得られます。
| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000 | P | | | | | | | 1 |
| 52a87f000 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | P |
| 52a8ff000 | | | | | | | P | 9 |
通常のleft-symmetricレイアウトが表示されます。これはmdadmのデフォルトです。さらに重要なことに、パーティションの順序がわかりました。ただし、循環的にシフトする可能性があるため、配列の最初のパーティションはわかりません。
見つかったオフセット間の距離にも注意してください。私の場合は512KBでした。チャンクサイズは実際にはこの距離よりも小さい場合があります。その場合、実際のレイアウトは異なります。
元のチャンクサイズを見つける
同じファイルpicture.jpgを使用して、互いに異なる間隔で32バイトのデータを読み取ります。上から、オフセット100kのデータは/dev/sdh2にあり、オフセット612kのデータは/dev/sdb2にあり、1124kのデータは/dev/sdd2にあることがわかります。これは、チャンクサイズが512KB以下であることを示しています。 512KB以上であることを確認しています。このために、オフセット356kでバイト文字列をダンプし、どのパーティションにあるかを調べます。
hexdump -n32 -s356k -v -e '/1 "%02X"' P1080801.JPG ; echo
7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A
Sudo ./bgrep 7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A /dev/sdb2
/dev/sdb2: 52a83f000
チャンクサイズが256KBではないことを示すオフセット612kと同じパーティションにあります。同様の方法で、より小さいチャンクサイズを削除します。結局、512KBのチャンクが唯一の可能性となりました。
レイアウトの最初のパーティションを見つける
これでパーティションの順序はわかりましたが、どのパーティションを最初にするか、どのRAIDデータオフセットを使用したかはわかりません。これら2つの未知のものを見つけるために、正しいチャンクレイアウトと小さなデータオフセットでRAID5アレイを作成し、この新しいアレイでファイルシステムの先頭を検索します。
まず、前に見つけたパーティションの正しい順序で配列を作成します。
Sudo mdadm --stop /dev/md126
Sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5 /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sda2 /dev/sdh2
次のコマンドを発行して、注文が遵守されていることを確認します
Sudo mdadm --misc -D /dev/md126
...
Number Major Minor RaidDevice State
0 8 18 0 active sync /dev/sdb2
1 8 50 1 active sync /dev/sdd2
2 8 34 2 active sync /dev/sdc2
3 8 66 3 active sync /dev/sde2
4 8 82 4 active sync /dev/sdf2
5 8 98 5 active sync /dev/sdg2
6 8 2 6 active sync /dev/sda2
7 8 114 7 active sync /dev/sdh2
次に、RAIDアレイ内のN + 1個の既知のバイト文字列のオフセットを決定します。私は一晩スクリプトを実行します（Live CDはSudoでパスワードを要求しません:)：
#!/bin/bash
echo "1st:"
Sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126
echo "2nd:"
Sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/md126
echo "3rd:"
Sudo ./bgrep BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA /dev/md126
...
echo "9th:"
Sudo ./bgrep 99B5A96F21BB74D4A630C519B463954EC096E062B0F5E325FE8D731C6D1B4D37 /dev/md126
コメント付きの出力：
1st:
/dev/md126: 2428fff000 # 1st
2nd:
/dev/md126: 242947f000 # 480000 after 1st
3rd: # 3rd not found
4th:
/dev/md126: 242917f000 # 180000 after 1st
5th:
/dev/md126: 24291ff000 # 200000 after 1st
6th:
/dev/md126: 242927f000 # 280000 after 1st
7th:
/dev/md126: 24292ff000 # 300000 after 1st
8th:
/dev/md126: 242937f000 # 380000 after 1st
9th:
/dev/md126: 24297ff000 # 800000 after 1st
このデータに基づいて、3番目の文字列が見つからなかったことがわかります。これは、/dev/sdd2のチャンクがパリティに使用されることを意味します。これは、新しいアレイのパリティ位置の図です。
| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000 | | | P | | | | | 1 |
| 52a87f000 | 2 | P | 4 | 5 | 6 | 7 | 8 | |
| 52a8ff000 | P | | | | | | | 9 |
私たちの目的は、パリティチャンクを適切な場所に移動するために、アレイを開始するパーティションを推測することです。パリティは2つのチャンクを左にシフトする必要があるため、パーティションシーケンスは右に2ステップシフトする必要があります。したがって、このデータオフセットの正しいレイアウトはahbdcefgです。
Sudo mdadm --stop /dev/md126
Sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5 /dev/sda2 /dev/sdh2 /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2
この時点で、RAIDアレイには正しい形式のデータが含まれています。 RAIDデータオフセットが元のアレイと同じになるように運が良ければ、パーティションをマウントできる可能性が高くなります。残念ながら、これは私のケースではありませんでした。
データの整合性を確認する
配列からpicture.jpgのコピーを抽出して、データがチャンクのストリップ全体で一貫していることを確認します。このため、32バイト文字列のオフセットを100kに配置します。
Sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126
次に、結果から100 * 1024を減算し、得られた10進数値をddのskip=パラメータで使用します。 count=はpicture.jpgのサイズ（バイト）です。
Sudo dd if=/dev/md126 of=./extract.jpg bs=1 skip=155311300608 count=4536208
extract.jpgがpicture.jpgと同じであることを確認します。
RAIDデータのオフセットを見つける
補足：mdadmバージョン3.2.3のデフォルトのデータオフセットは2048セクターです。ただし、この値は時間の経過とともに変更されています。元の配列が現在のmdadmよりも小さいデータオフセットを使用した場合、mdadm --createなしの--assume-cleanはファイルシステムの先頭を上書きする可能性があります。
前のセクションでは、RAIDアレイを作成しました。個々のパーティションのいくつかに対して発行することで、どのRAIDデータオフセットがあったかを確認します。
Sudo mdadm --examine /dev/sdb2
...
Data Offset : 2048 sectors
...
2048 512バイトセクターは1MBです。チャンクサイズは512KBなので、現在のデータオフセットは2つのチャンクです。
この時点で2チャンクのオフセットがある場合、それはおそらく十分に小さいので、この段落はスキップできます。
1つの512KBチャンクのデータオフセットでRAID5アレイを作成します。 1つのチャンクを早く開始すると、パリティが1ステップ左にシフトします。したがって、パーティションシーケンスを1ステップ左にシフトすることで補正します。したがって、512KBのデータオフセットの場合、正しいレイアウトはhbdcefgaです。データオフセットをサポートするmdadmのバージョンを使用します（「ツール」セクションを参照）。キロバイト単位のオフセットが必要です。
Sudo mdadm --stop /dev/md126
Sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5 /dev/sdh2:512 /dev/sdb2:512 /dev/sdd2:512 /dev/sdc2:512 /dev/sde2:512 /dev/sdf2:512 /dev/sdg2:512 /dev/sda2:512
次に、有効なext4スーパーブロックを検索します。スーパーブロックの構造はここにあります： https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
配列の先頭をスキャンして、マジック番号s_magicの後にs_stateとs_errorsが続くかどうかをスキャンします。検索するバイト文字列は次のとおりです。
53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200
コマンドの例：
Sudo ./bgrep 53EF01000100 /dev/md126
/dev/md126: 0dc80438
マジック番号はスーパーブロックの0x38バイトから始まるため、0x38を減算してオフセットを計算し、スーパーブロック全体を調べます。
Sudo hexdump -n84 -s0xDC80400 -v /dev/md126
dc80400 2000 00fe 1480 03f8 cdd3 0032 d2b2 0119
dc80410 ab16 00f7 0000 0000 0002 0000 0002 0000
dc80420 8000 0000 8000 0000 2000 0000 b363 51bd
dc80430 e406 5170 010d ffff ef53 0001 0001 0000
dc80440 3d3a 50af 0000 0000 0000 0000 0001 0000
dc80450 0000 0000
これは有効なスーパーブロックのようです。 0x18のs_log_block_sizeフィールドは0002です。これは、ブロックサイズが2 ^（10 + 2）= 4096バイトであることを意味します。 0x4のs_blocks_count_loは03f81480ブロックで、254GBです。いいね。
次に、スーパーブロックの最初のバイトの出現をスキャンして、そのコピーを見つけます。 hexdumpの出力と比較して、バイトフリッピングに注意してください。
Sudo ./bgrep 0020fe008014f803d3cd3200 /dev/md126
/dev/md126: 0dc80400 # offset by 1024 bytes from the start of the FS
/dev/md126: 15c80000 # 32768 blocks from FS start
/dev/md126: 25c80000 # 98304
/dev/md126: 35c80000 # 163840
/dev/md126: 45c80000 # 229376
/dev/md126: 55c80000 # 294912
/dev/md126: d5c80000 # 819200
/dev/md126: e5c80000 # 884736
/dev/md126: 195c80000
/dev/md126: 295c80000
これは、バックアップスーパーブロックの予想される位置と完全に一致します。
Sudo mke2fs -n /dev/md126
...
Block size=4096 (log=2)
...
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
したがって、ファイルシステムはオフセット0xdc80000、つまりパーティションの開始から225792KBで始まります。 8つのパーティションがあり、そのうちの1つはパリティ用であるため、オフセットを7で除算します。これにより、すべてのパーティションで33030144バイトのオフセットが得られます。これは、正確に63 RAIDチャンクです。また、現在のRAIDデータオフセットは1つのチャンクであるため、元のデータオフセットは64チャンク、つまり32768KBであったと結論付けます。 hbdcefgaを右に63回シフトすると、レイアウトはbdcefgahになります。
最終的に正しいRAIDアレイを構築します。
Sudo mdadm --stop /dev/md126
Sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5 /dev/sdb2:32768 /dev/sdd2:32768 /dev/sdc2:32768 /dev/sde2:32768 /dev/sdf2:32768 /dev/sdg2:32768 /dev/sda2:32768 /dev/sdh2:32768
Sudo fsck.ext4 -n /dev/md126
e2fsck 1.42 (29-Nov-2011)
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/md126: clean, 423146/16654336 files, 48120270/66589824 blocks
Sudo mount -t ext4 -r /dev/md126 /home/xubuntu/mp
ほら！
あなたがラッキーである場合、壊れたRAID-5アレイを読み取ることができる回復ソフトウェアでファイルを取り戻すことに成功するかもしれません。 ゼロ仮定回復 は、私が以前に成功したものです。
ただし、新しいアレイを作成するプロセスが完了してすべてのデータが破壊されたかどうかは不明なので、これが最後のチャンスになるかもしれません。
同様の問題がありました。 Ubuntu 12.04のクリーンインストールでOS /ブートドライブをフォーマットして再インストールした後、mdadm --create ...コマンドを実行してマウントできませんでした。
有効なスーパーブロックまたはパーティションがないとのことです。
さらに、mdadm raidを停止すると、通常のデバイスをマウントできなくなりました。
私はmke2fsとe2fsckでスーパーブロックを修復することができました：
root@blackbox:~# mke2fs -n /dev/sdc1
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
91578368 inodes, 366284000 blocks
18314200 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
11179 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
次に実行しました：
e2fsck -b 32768 -y /dev/sdc1
これでスーパーブロックが復元されたので、ドライブをマウントして読み取ることができました。
ビルドで使用したスーパーブロックまたはパーティションを破壊せずにアレイを機能させるには：
mdadm --build /dev/md0 --level=mirror --assume-clean --raid-devices=2 /dev/sdc1 missing
データを確認したら、他のドライブを追加します。
mdadm --add /dev/md0 /sdd1
以前に提供した情報の一部を更新しています。私のマザーボードが死んだとき、私は3ディスクraid5アレイが問題なく動作していました。アレイは/ dev/md2を/ homeパーティション1.2TBとして、/ dev/md3を/ varパーティション300GBとして保持しました。
「重要」なもののバックアップを2つと、インターネットのさまざまな部分から手に入れて、実際に通過して選択的にダンプする必要があるランダムなものの束を用意しました。ほとんどのバックアップは25GB以下の.tar.gzファイルに分割され、/ etcの個別のコピーもバックアップされました。
ファイルシステムの残りの部分は、38GBの2つの小さなraid0ディスクに保持されていました。
私の新しいマシンは古いハードウェアに似ていて、5つすべてのディスクを接続し、古い汎用カーネルを選択するだけで、マシンを稼働させました。したがって、クリーンなファイルシステムを備えた5つのディスクがありましたが、ディスクが正しい順序であるかどうかはわかりませんでした。また、必要に応じてマシンを確実にアップグレードできるように、新しいバージョンのDebian Jessieをインストールする必要がありました。問題。
2つのRaid0ディスクに新しい汎用システムがインストールされたので、アレイを元に戻し始めました。ディスクが正しい順序になっていることを確認したかったのです。私がやるべきだったのは発行することでした：
mdadm --assemble /dev/md3 -o --no-degraded --uuid=82164ae7:9af3c5f1:f75f70a5:ba2a159a
しかし、私はしませんでした。 mdadmはかなりスマートで、uuidが与えられているため、どのドライブがどこに移動するかを把握できます。 biosが/ dev/sdcを/ sdaとして指定している場合でも、mdadmはそれを正しくまとめます（YMMVです）。
代わりに私は発行しました：mdadm --create /dev/md2 without the --assume-clean、/ dev/sde1での再同期の完了を許可しました。次に犯した間違いは、/ dev/md2の最後のドライブ/ sde1ではなく、/ dev/sdc1で作業することでした。 mdadmが問題があると考えるときはいつでも、それが追い出されるか再同期される最後のドライブです。
その後、mdadmはスーパーブロックを見つけることができず、e2fsck -nも見つけることができませんでした。
このページを見つけた後、ドライブのシーケンスを見つけ（完了）、有効なデータを確認し（9MBファイルの6MBを確認）、正しい順序でディスクを取得し、cde、uuidを取得する手順を実行しました古い/etc/mdadm.confの/ md2と/ md3を使用してアセンブルを試みました。
上手、 /dev/md3開始、およびmdadm --misc -D /dev/md3は、3つの正常なパーティションとディスクを正しい順序で示しました。 /dev/md2ファイルシステムをマウントしようとするまで、見栄えも良かった。
# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Wed Feb 3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
size=585936896K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Wed Feb 3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
size=585936896K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Wed Feb 3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.
ファイルシステムはマウントを拒否し、e2fsckはスーパーブロックを見つけることができませんでした。さらに、上記のようにスーパーブロックをチェックすると、a880 0076またはa880 0076または5500 1176として検出された合計ブロック数が、1199.79のディスク容量サイズと一致しませんでした。また、上記の投稿のデータと一致する「スーパーブロック」の場所はありません。
/ varをすべてバックアップし、ディスクをワイプする準備をしました。/md2だけをワイプできるかどうかを確認するために（この時点で他に失うものは何もありませんでした）、次のことを行います。
root@ced2:/home/richard# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Wed Feb 3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
size=585936896K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Wed Feb 3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
size=585936896K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Wed Feb 3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.
# mkfs.ext3 /dev/md2
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 292902912 4k blocks and 73228288 inodes
Filesystem UUID: a54e252f-78db-4ebb-b7ca-7dcd2edf57a4
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
# hexdump -n84 -s0x00000400 -v /dev/md2
0000400 6000 045d 5800 1175 7799 00df 6ff0 112e
0000410 5ff5 045d 0000 0000 0002 0000 0002 0000
0000420 8000 0000 8000 0000 2000 0000 10d3 56b2
0000430 10d3 56b2 0002 ffff ef53 0001 0001 0000
0000440 0c42 56b2 0000 0000 0000 0000 0001 0000
0000450 0000 0000
0000454
# ./bgrep 00605D0400587511 /dev/md2
/dev/md2: 00000400
/dev/md2: 08000000
/dev/md2: 18000000
/dev/md2: 28000000
/dev/md2: 38000000
/dev/md2: 48000000
/dev/md2: c8000000
/dev/md2: d8000000
/dev/md2: 188000000
/dev/md2: 288000000
/dev/md2: 3e8000000
/dev/md2: 798000000
/dev/md2: ab8000000
etc
Uuidへの変更を除いて、すべて問題ありません。そのため、さらにいくつかのチェックを行った後、600GBのバックアップデータを/ dev/md2に書き込みました。次に、マウントを解除してドライブを再マウントしようとしました：
# mdadm --assemble /dev/md2 uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7
mdadm: cannot open device uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7: No such file or directory
mdadm: uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 has no superblock - Assembly aborted
私をからかってるの？ファイルの600 GBはどうですか？
# mdadm --assemble /dev/md2
mdadm: /dev/md2 not identified in config file.
ああ-簡単に修正。 /etc/mdadm.confのコメントを外した1行
# mdadm --assemble /dev/md2
mdadm: /dev/md2 has been started with 3 drives.
# e2fsck -n /dev/md2
e2fsck 1.42.12 (29-Aug-2014)
/dev/md2: clean, 731552/73228288 files, 182979586/292902912 blocks
イッピー！