Bri*_*ren 36 mdadm data-recovery raid5
伙计们请帮忙 - 我是一个手头严重头痛的新手（完美的风暴情况）。
我的 ubuntu 11.04 上有一个 3 1tb 硬盘，配置为软件 raid 5。数据每周都被复制到另一个独立的计算机硬盘驱动器上，直到完全失败并被丢弃。几天前，我们停电了，重新启动后我的盒子无法安装突袭。我以无限的智慧进入
mdadm --create -f...
命令而不是
mdadm --assemble
直到之后才注意到我所做的讽刺。它启动了阵列降级并继续构建和同步它，耗时约 10 小时。回来后我看到阵列成功启动并运行，但raid没有
我的意思是单个驱动器已分区（分区类型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 (22-Dec-2010) fsck.ext4：超级块无效，正在尝试备份块... fsck.ext4：超级中的错误幻数试图打开 /dev/md0 时阻塞
无法读取超级块或未描述正确的 ext2 文件系统。如果设备有效并且它确实包含一个 ext2 文件系统（而不是交换或 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>
有什么建议？
问候！
Sha*_*den 93
好的 - 关于你的问题，我有一些问题，所以我启动了一个虚拟机来深入研究应该预期的行为。我会在一分钟内解决困扰我的问题；首先让我这样说：
在尝试任何操作之前备份这些驱动器！！
您可能已经造成了超出重新同步所做的损害；你能澄清一下你说的意思吗：
根据建议，我确实清理了超级块并使用 --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
好的。我们有一个文件系统和一些数据（“data” in datafile，以及价值 5MB 的随机数据，其中包含 SHA1 散列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>
不！这是为什么？因为虽然数据都在那里，但它的顺序是错误的；曾经是 A 的 512KB，然后是 B、A、B 等的 512KB，现在已经被随机分配到 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它看看你是否有任何有希望的东西。所以，就是这样。对不起小说，如果您有任何问题，请随时发表评论，祝您好运！
脚注：22000字以内；比长度限制少 8k+
小智 6
我有一个类似的问题：
在软件 RAID5 阵列出现故障后，我mdadm --create没有给出它就解雇了--assume-clean，并且无法再安装该阵列。经过两周的挖掘，我终于恢复了所有数据。我希望下面的程序可以节省一些人的时间。
问题是因为mdadm --create做了一个新的数组，在两个方面与原来的不同：
因为它是在辉煌被证明由巴蒂尔劲爆答案，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
然后连接外部 HDD 并备份 RAID 阵列的每个分区，如下所示：
sudo dd if=/dev/sda2 bs=4M | gzip > serial-number.gz
此处描述了各种布局：http : //www.accs.com/p_and_p/RAID/LinuxRAID.html
要了解数据条是如何在原始阵列上组织的，您需要一份随机外观文件的副本，您知道该文件是存储在数组中。当前使用的默认块大小mdadm为 512KB。对于 N 个分区的数组，您需要一个大小至少为 (N+1)*512KB 的文件。jpeg 或视频很好，因为它提供了相对独特的二进制数据子串。假设我们的文件名为picture.jpg. 我们在 N+1 个位置读取 32 个字节的数据，从 100k 开始并以 512k 递增：
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
和offset 612k在同一个分区，说明chunk size不是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
根据此数据，我们看到未找到第三个字符串。这意味着块 at/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=参数 for 中使用获得的十进制值dd。的count=是的大小picture.jpg以字节计：
sudo dd if=/dev/md126 of=./extract.jpg bs=1 skip=155311300608 count=4536208
检查extract.jpg是否与picture.jpg.
旁注：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
这似乎是一个有效的超级块。s_log_block_size0x18 处的字段为 0002，这意味着块大小为 2^(10+2)=4096 字节。s_blocks_count_lo0x4 处是 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 数据偏移量为 1 个块，因此我们得出原始数据偏移量为 64 个块，即 32768 KB。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
瞧！
| 归档时间： |
|
| 查看次数： |
24607 次 |
| 最近记录： |