如何恢复突袭？ mount：无法读取超级块

我用mdadm创build了/ dev / md0上的raid5数组，它工作正常大约一年。它由三个1TB的硬盘组成。几天前发生电源故障和UPS故障。这不幸是第一次。

操作系统位于单独的SSD磁盘（ / dev / sda ），它不是RAIDarrays的一部分，因此它启动，但不能再安装arrays。有时/ dev / md0根本不存在。另外我做了一些可能让事情变得更糟的事情。我运行了fsck /dev/sdb -y ，它在磁盘上写了很多次。

我害怕，我不会恢复我的文件。你能帮我解决这个问题吗？

谢谢。

mount / dev / md0 / mnt / raid5

 mount: /dev/md0: can't read superblock

系统日志：

 Feb 25 15:59:53 pve kernel: [ 365.559378] EXT4-fs (md0): unable to read superblock Feb 25 15:59:53 pve kernel: [ 365.560118] EXT4-fs (md0): unable to read superblock Feb 25 15:59:53 pve kernel: [ 365.560216] EXT4-fs (md0): unable to read superblock Feb 25 15:59:53 pve kernel: [ 365.560310] FAT-fs (md0): unable to read boot sector

cat / proc / mdstat

 Personalities : [raid6] [raid5] [raid4] unused devices: <none>

fdisk -l

 Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x75633c0d Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 1950353407 1950351360 930G fd Linux raid autodetect Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: F397C12B-1549-45EA-97EA-6A41B713B58F Device Start End Sectors Size Type /dev/sdc1 2048 1950353407 1950351360 930G Linux RAID Disk /dev/sdd: 931.5 GiB, 1000203804160 bytes, 1953523055 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xcced27e3 Device Boot Start End Sectors Size Id Type /dev/sdd1 2048 1950353407 1950351360 930G fd Linux raid autodetect

有时fdisk -l

 -bash: /sbin/fdisk: Input/output error

系统日志：

 Feb 25 16:03:25 pve kernel: [ 577.221547] ata1.00: SRST failed (errno=-16) Feb 25 16:03:25 pve kernel: [ 577.232569] ata1.00: reset failed, giving up Feb 25 16:03:25 pve kernel: [ 577.232640] ata1.00: disabled Feb 25 16:03:25 pve kernel: [ 577.232643] ata1.01: disabled Feb 25 16:03:25 pve kernel: [ 577.232658] ata1: EH complete Feb 25 16:03:25 pve kernel: [ 577.232683] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Feb 25 16:03:25 pve kernel: [ 577.232697] sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 05 13 a0 38 00 00 08 00 Feb 25 16:03:25 pve kernel: [ 577.232702] blk_update_request: I/O error, dev sda, sector 85172280 Feb 25 16:03:25 pve kernel: [ 577.232784] Buffer I/O error on dev dm-6, logical block 9255, lost sync page write Feb 25 16:03:25 pve kernel: [ 577.232928] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK Feb 25 16:03:25 pve kernel: [ 577.232936] sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 02 88 6a 10 00 00 68 00 Feb 25 16:03:25 pve kernel: [ 577.232941] blk_update_request: I/O error, dev sda, sector 42494480 Feb 25 16:03:25 pve kernel: [ 577.232948] EXT4-fs error (device dm-6): kmmpd:176: comm kmmpd-dm-6: Error writing to MMP block

编辑1：

sudo mdadm –examine / dev / sdb1

 mdadm: No md superblock detected on /dev/sdb1.

sudo mdadm –examine / dev / sdc1

 /dev/sdc1: Magic : a92b4efc Version : 1.2 Feature Map : 0x1 Array UUID : 34c11bda:11bbb8c9:c4cf5f56:7c38e1c3 Name : pve:0 Creation Time : Sun Jun 5 21:06:33 2016 Raid Level : raid5 Raid Devices : 3 Avail Dev Size : 1950089216 (929.88 GiB 998.45 GB) Array Size : 1950089216 (1859.75 GiB 1996.89 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262056 sectors, after=0 sectors State : active Device UUID : be76ecf7:b0f28a7d:718c3d58:3afae9f7 Internal Bitmap : 8 sectors from superblock Update Time : Mon Feb 20 14:48:51 2017 Bad Block Log : 512 entries available at offset 72 sectors Checksum : ffbc1988 - correct Events : 2901112 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 1 Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)

sudo mdadm –examine / dev / sdd1

 /dev/sdd1: Magic : a92b4efc Version : 1.2 Feature Map : 0x9 Array UUID : 34c11bda:11bbb8c9:c4cf5f56:7c38e1c3 Name : pve:0 Creation Time : Sun Jun 5 21:06:33 2016 Raid Level : raid5 Raid Devices : 3 Avail Dev Size : 1950089216 (929.88 GiB 998.45 GB) Array Size : 1950089216 (1859.75 GiB 1996.89 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262056 sectors, after=0 sectors State : active Device UUID : 7b9ed6e0:ffad7603:b226e752:355765a8 Internal Bitmap : 8 sectors from superblock Update Time : Mon Feb 20 14:48:51 2017 Bad Block Log : 512 entries available at offset 72 sectors - bad blocks present. Checksum : 19b6f3da - correct Events : 2901112 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 2 Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)

如果你给input/输出错误，我认为你有一个或多个坏的磁盘。您需要通过命令smartctl -a /dev/sdx来检查所有磁盘的SMART属性。使用命令mdadm --examine /dev/sdx1检查每个磁盘的status和Update Time 。 select一个最坏的磁盘女巫有更多的坏智能属性和最旧的Update Time ，并从arrays中删除它。

如果你有两个坏的磁盘，你需要select较less的坏磁盘，它必须通过程序ddrecovery恢复到新的磁盘。删除这个坏的磁盘，并将新恢复的磁盘插入到相同的地方。

然后你可以用一个错过的磁盘（例如sdc ）通过命令恢复RAID 5arrays：

 mdadm --verbose --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 missing /dev/sdd1

确保chunk参数与正常磁盘上的相同。

你也有坏的SD磁盘，这不是RAID 5arrays的成员。

谨慎处理每个命令。只有这样才能恢复你的RAIDarrays。

阅读这个例子。

感谢所有我恢复的数据。

我运行sudo mdadm --verbose --assemble --force /dev/md0 /dev/sdc1 /dev/sdd1从剩下的两个好的硬盘组装好这个arrays，它就起作用了！

然后我格式化sdb，并用sudo mdadm --manage /dev/md0 --add /dev/sdb1将其重新添加到数组中，然后我将购买一个新的快速replace它。另外我正在寻找备份解决scheme..

运行fsck是正确的想法，但我认为你运行在错误的设备上。尝试使用备份超级块在/ dev / md0上运行fsck。这个链接将给你一些关于如何find备份和修复的提示。尤其是，运行dumpe2fs是查找文件系统块大小的最佳select。即使第一个备份被损坏，ext4也会创build其他的。

你有几个问题。

首先，您说/ dev / sda是您的系统磁盘，不是RAIDarrays的一部分，其上带有操作系统。那么，请查看您向我们展示的确切的系统日志片段：

 Feb 25 16:03:25 pve kernel: [ 577.232702] blk_update_request: I/O error, dev sda, sector 85172280 Feb 25 16:03:25 pve kernel: [ 577.232941] blk_update_request: I/O error, dev sda, sector 42494480

写入期间的两个I / O错误，在一个毫秒内报告给系统磁盘上的两个不同位置。您的系统磁盘存在严重问题; 立即取代它。当你处于这个状态的时候，可能还是值得更换布线的。根据我的经验，I / O错误通常表示布线或磁盘问题（尽pipeHBA 可能存在问题）。由于这个问题，期望系统磁盘上的数据至less在某种程度上被破坏。

其次， fsck /dev/sdb -y很有可能在你的RAID数据上乱写乱画，试图理解部分文件系统数据，并自动写出它认为正确的东西。我会build议物理断开该磁盘，将其从系统中删除，并将其放置在一个安全的地方。把它当作死亡。

谢天谢地，你很幸运。系统仍在与所有三个磁盘进行通信，并且元数据在三个仍然保存md元数据的两个磁盘上看起来很理智。

抓住三个新的磁盘，并使用ddrescue从剩下的两个磁盘复制到两个新的磁盘。拔下旧的磁盘，并将它们与以前的/ dev / sdb一起设置（确保你跟踪哪个磁盘是哪个磁盘），然后插入两个新磁盘以及第三个新的空白磁盘。

将生成的数组提供给mdadm，并向你的神祗祈祷，以便md能够理解所产生的情况。如果你幸运的话，它将能够，并将大部分数据恢复到可读状态，因为没有读错误（因为你带了新的磁盘）。再次，地方可能会有一些腐败。

第三，找出造成UPS故障并纠正的原因，并build立定期的备份，以便在最坏的情况发生时，至less你将有一个备份，你可以恢复到新的媒体上。考虑这个事件是一个学习经验，说明为什么RAID不是备份。