☰

编辑1：

tag-icon • tag-icon mdadm
编辑1：

我有一个 raid5 阵列/dev/md0使用 mdadm 创建，运行良好，大约一年了。它由三个 1TB 的硬盘组成。几天前发生了电源故障和 UPS 故障。不幸的是，这不是第一次了。

操作系统位于单独的 SSD 磁盘上（/dev/sda) 不是 RAID 阵列的一部分，因此它可以启动，但无法再挂载该阵列。有时/dev/md0根本不存在。我还做了一些可能让事情变得更糟的事情。我运行了fsck /dev/sdb -y在磁盘上写入很多次的操作。

我担心我无法恢复我的文件。你能帮我解决这个问题吗？

谢谢。

挂载 /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

猫/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 --检查 /dev/sdb1

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

sudo mdadm --检查 /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 --检查 /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)

答案1

感谢大家，我恢复了数据。

我跑去sudo mdadm --verbose --assemble --force /dev/md0 /dev/sdc1 /dev/sdd1用剩下的两个好硬盘来组装阵列，它成功了！

然后我格式化了 sdb 并将其重新添加到阵列中sudo mdadm --manage /dev/md0 --add /dev/sdb1，我打算很快买一个新的来替换它。我也在寻找备份解决方案。

答案2

如果您给出输入/输出错误，我认为您有一个或多个坏磁盘。您需要使用命令检查所有磁盘的 SMART 属性smartctl -a /dev/sdx。使用命令检查status每个Update Time磁盘mdadm --examine /dev/sdx1。选择一个具有更多坏智能属性且最旧的最差磁盘，Update Time并将其从阵列中删除。

如果您有两个坏盘，则需要选择坏盘较少的盘，并且必须通过程序将其恢复到新磁盘ddrecovery。移除此坏盘并将新恢复的磁盘插入到同一位置。

然后，您将可以使用以下命令恢复具有一个丢失磁盘的 RAID 5 阵列（例如sdc）：

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

确保该chunk参数与良好磁盘上的参数相同。

另外，您有一个坏的 sda 磁盘，它不是 RAID 5 阵列的成员。

小心执行每个命令。只有一种方法可以恢复您的 RAID 阵列。

读这举例来说。

答案3

运行 fsck 是个好主意，但我认为您在错误的设备上运行了它。尝试使用备份超级块在 /dev/md0 上运行 fsck。此链接会给你一些关于如何找到备份并在你找到时进行修复的提示。特别是，运行dumpe2fs是查找文件系统块大小的最佳选择。即使第一个备份已损坏，ext4 也会创建其他备份。

答案4

你有几个问题。

第一的，您说 /dev/sda 是系统磁盘，不是 RAID 阵列的一部分，上面装有操作系统。好吧，看看您向我们展示的确切系统日志片段：

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 错误通常表示电缆或磁盘问题（尽管 HBA能可能是故障）。此问题可能会导致系统磁盘上的数据至少在一定程度上损坏。

第二， fsck /dev/sdb -y很可能在尝试理解部分文件系统数据时在您的 RAID 数据上乱涂乱画，并自动写出它认为正确的内容。我建议物理断开该磁盘，将其从系统中移除，并将其放置在安全的地方。将其视为已损坏。

值得庆幸的是，你很幸运；系统仍在与所有三个磁盘通信，并且在三个磁盘中仍然保存 md 元数据的两个磁盘上的元数据看起来是正常的。

取出三块新磁盘，将ddrescue剩余两块磁盘上的所有东西复制到两块新磁盘上。拔下旧磁盘，将它们与以前的 /dev/sdb 放在一起（确保记住哪个磁盘是哪个），然后将两块新磁盘与第三块新的空白磁盘一起插入。

将生成的阵列提供给 mdadm，然后向您选择的神祈祷，希望 md 能够理解结果情况。如果您幸运的话，它将能够理解结果情况，并且现在没有读取错误（因为您引入了新磁盘），它将恢复大部分数据到可读状态。同样，某些地方可能存在损坏。

第三，找出导致 UPS 故障的原因并纠正它，并设置定期备份，这样如果发生最坏的情况，至少你会有一个可以恢复到新媒体上的备份。把这个事件当作一个学习经历，说明为什么 RAID 不是备份。

相关内容