大家请帮帮我 - 我是一个新手，手头上有一个大麻烦（完美风暴情况）。
我的 ubuntu 11.04 上有 3 个 1TB 硬盘，配置为软件 raid 5。数据每周都会复制到另一个单独的计算机硬盘上，直到它完全失效并被扔掉。几天前我们停电了，重启后我的盒子无法安装 raid。我凭着无限的智慧输入了
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 的主机 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 (2010 年 12 月 22 日) fsck.ext4：超级块无效，正在尝试备份块... fsck.ext4：尝试打开 /dev/md0 时超级块中的幻数错误
无法读取超级块，或者超级块未描述正确的 ext2 文件系统。如果设备有效，并且确实包含 ext2 文件系统（而不是 swap 或 ufs 或其他文件系统），则超级块已损坏，您可以尝试使用备用超级块运行 e2fsck：e2fsck -b 8193
根据 Shanes 的建议，我尝试了
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>
有什么建议么？
问候！
答案1
好的 - 您的问题让我有些困扰，所以我启动了虚拟机来深入了解应该出现的行为。我马上就会知道是什么困扰着我；首先让我说一下：
在尝试任何操作之前请先备份这些驱动器！！
您可能已经造成了超出重新同步所造成的损害；您能否解释一下您所说的意思：
根据建议，我确实清理了超级块并使用 --assume-clean 选项重新创建了数组，但没有任何效果。
如果您运行了mdadm --misc --zero-superblock，那么您应该没问题。
无论如何，在执行任何可能对这些磁盘进行写入的操作之前，请清理一些新磁盘并获取它们的精确当前图像。
dd if=/dev/sdd of=/path/to/store/sdd.img
话虽如此……看起来，这些东西上存储的数据对反复无常的重新同步具有惊人的弹性。继续阅读，还有希望，也许有一天我会达到答案长度的限制。
最好的情况
我拼凑了一个虚拟机来重现您的场景。驱动器只有 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
好的。我们有一个文件系统和一些数据（中的“数据” datafile，以及中的带有 SHA1 哈希的 5MB 随机数据randomdata）；让我们看看重新创建时会发生什么。
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
稳定 - 完全没有数据损坏！但这是使用完全相同的设置，因此两个 RAID 组之间的映射没有任何不同。在我们试图破坏它之前，让我们把它放下来。
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
退一步
在我们尝试破解它之前，让我们先讨论一下为什么它很难破解。RAID 5 的工作原理是使用奇偶校验块来保护与阵列中每个其他磁盘上的块大小相同的区域。奇偶校验不只在一个特定的磁盘上，它会均匀地在磁盘上旋转，以便在正常运行时更好地将读取负载分散到磁盘上。
计算奇偶校验的 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>
好的，一切都很好。我们有文件系统吗？
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
再次成功！
测试 3
我认为这肯定会破坏数据 - 让我们做一个不同的布局算法！
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！！ - 尝试
fsck当前活动的 md - 您可能恰好按照与之前相同的顺序进行构建。如果您知道文件系统类型，那会很有帮助；请使用该特定fsck工具。如果任何工具提出修复任何问题，除非您确定他们确实找到了有效的文件系统，否则不要让他们修复！如果有人fsck提出为您修复某些问题，请毫不犹豫地发表评论，询问它是否真的有帮助，还是即将删除数据。 - 尝试使用不同的参数构建数组。如果您有一个旧的
/proc/mdstat，那么您可以模仿它显示的内容；如果没有，那么您就有点摸不着头脑了——尝试所有不同的驱动器顺序是合理的，但检查每个可能的顺序的每个可能的块大小是徒劳的。对于每一个，fsck看看你是否得到了任何有希望的东西。
就这样吧。抱歉，内容太长了，如果您有任何问题，请随时发表评论，祝您好运！
脚注：少于 22,000 个字符；距离长度限制还有 8k+
答案2
我遇到了类似的问题：
软件 RAID5 阵列发生故障后，我启动了mdadm --create它--assume-clean，但没有给出任何提示，因此无法再安装该阵列。经过两周的挖掘，我终于恢复了所有数据。我希望下面的步骤可以节省一些人的时间。
长话短说
问题是由于mdadm --create创建了一个新数组，该数组在两个方面与原始数组不同：
- 不同的分区顺序
- 不同的 RAID 数据偏移
正如在精彩的Shane Madden 的回答，mdadm --create在大多数情况下不会破坏数据！找到分区顺序和数据偏移量后，我可以恢复阵列并从中提取所有数据。
先决条件
我没有 RAID 超级块的备份，所以我只知道它是在安装 Xubuntu 12.04.0 时创建的 8 个分区上的 RAID5 阵列。它有一个 ext4 文件系统。另一个重要的知识是也存储在 RAID 阵列上的文件的副本。
工具
Xubuntu 12.04.1 live 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、mount 和十六进制计算器- 来自 repos 的标准工具
从完整备份开始
设备文件的命名（例如/dev/sda2 /dev/sdb2等）不是持久的，因此最好记下驱动器的序列号，如下所示
sudo hdparm -I /dev/sda
然后连接外部硬盘并备份 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 为增量，在 N+1 个位置读取 32 字节数据：
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
...
然后我们在所有原始分区上搜索所有这些字节串的出现情况，因此总共有 (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 字节字符串只出现一次。通过比较 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 |
我们看到的是正常的左对称布局，这是 的默认设置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
它与偏移量 612k 位于同一分区，这表明块大小不是 256KB。我们以类似的方式排除较小的块大小。我最终发现 512KB 块是唯一的可能性。
查找布局中的第一个分区
现在我们知道了分区的顺序，但我们不知道哪个分区应该是第一个，以及使用了哪个 RAID 数据偏移。为了找到这两个未知数，我们将创建一个具有正确块布局和较小数据偏移的 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 |
我们的目标是推断从哪个分区开始阵列，以便将奇偶校验块移到正确的位置。由于奇偶校验应向左移动两个块，因此分区序列应向右移动两步。因此，此数据偏移的正确布局是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，并将得到的十进制值用于skip=的参数dd。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，因此当前数据偏移量为两个块。
如果此时您有两个块偏移，则它可能足够小，您可以跳过本段。
我们创建一个 RAID5 阵列，其数据偏移量为一个 512KB 块。较早开始一个块会将奇偶校验向左移动一步，因此我们通过将分区序列向左移动一步来进行补偿。因此，对于 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
这似乎是一个有效的超级块。0x18s_log_block_size处的字段为 0002，这意味着块大小为 2^(10+2)=4096 字节。0x4s_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 个分区，其中一个用于奇偶校验，因此我们将偏移量除以 7。这为每个分区提供了 33030144 字节的偏移量，正好是 63 个 RAID 块。由于当前 RAID 数据偏移量为一个块，因此我们得出结论，原始数据偏移量为 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
瞧！
答案3
如果你是幸运的您可能会成功使用可以读取损坏的 RAID-5 阵列的恢复软件恢复文件。零假设恢复是我以前成功过的方法。
但是，我不确定创建新数组的过程是否已经完成并破坏了所有数据，因此这可能是最后一次机会。
答案4
我只是更新了之前给出的一些信息。我的主板坏了，但我有一个 3 磁盘 raid5 阵列，工作正常。该阵列将 /dev/md2 作为 /home 分区 1.2TB，将 /dev/md3 作为 /var 分区 300GB。
我备份了两份“重要”内容和一堆从互联网上抓取的随机内容，我真的应该仔细检查并有选择地转储它们。大多数备份都被分成 25GB 或更小的 .tar.gz 文件，并且还备份了一份单独的 /etc 副本。
文件系统的其余部分保存在两个 38GB 的小型 raid0 磁盘上。
我的新机器与旧硬件类似，我只需插入所有五个磁盘并选择旧的通用内核即可启动并运行机器。因此，我有五个带有干净文件系统的磁盘，尽管我不能确定磁盘的顺序是否正确，并且需要安装新版本的 Debian Jessie 以确保我可以在需要时升级机器并解决其他问题。
在两个 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/sdc1，而不是 /dev/md2 中的最后一个驱动器 /sde1。任何时候 mdadm 认为存在问题，都是最后一个驱动器被踢出或重新同步。
此后，mdadm 找不到任何超级块，e2fsck -n 也找不到。
找到这个页面后，我尝试查找驱动器的序列（完成），检查有效数据（验证了 9MB 文件中的 6MB），按正确的顺序获取磁盘，cde，从旧的 /etc/mdadm.conf 中获取 /md2 和 /md3 的 uuid，然后尝试组装。
好了，/dev/md3开始了，并mdadm --misc -D /dev/md3显示了三个健康的分区，并且磁盘的顺序正确。/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，与我的 mdadm 报告的磁盘容量大小 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
你是在跟我开玩笑吗？我的 600GB 文件怎么办？
# mdadm --assemble /dev/md2
mdadm: /dev/md2 not identified in config file.
啊 - 很容易修复。取消注释 /etc/mdadm.conf 中的一行
# 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
耶！