☰

RAID 上的卷发生故障-如何处理？

tag-icon • tag-icon raid ext3 fsck
RAID 上的卷发生故障-如何处理？

我最近接手了一场 RAID，遇到了一些情况，确实需要一些建议。希望我没有把事情搞砸。

我管理的临时集群中的几台服务器开始报告磁盘问题。我对其中一台运行了 fsck，对另一台运行了 xfs_repair。第一台似乎已修复，第二台没有报告问题。它们可以以读写方式挂载，并且会对某些文件产生读取错误。

我将这些磁盘追溯到单个 RAID：

  • JetStor 416iS
  • 16 个 750GB 硬盘
  • 具有多个数据卷的单卷组，RAID 6

查看 JetStor 管理界面：

  • 两个驱动器被列为故障
  • 6 个驱动器被列为缺陷
  • 三个用户卷被列为失败（对我来说，两个比另一个更重要）

以下是我所做的：

  1. 将所有分区重新安装为只读或卸载它们。（尽管 JetStor 支持人员表示这没有必要。该设备已过保修期，但他们为我回答了这个问题）
  2. 更换（热插拔）两个故障驱动器并重建它们。
  3. 更换（热插拔）两个标记为“缺陷”的驱动器并让它们重建。这两个驱动器与 JetStor 管理面板中两个更重要的故障用户卷相关联。
  4. 创建了几个新的用户卷作为更大的替换卷并充当中间存储。
  5. 尝试重新安装两个失败的卷。现在它们根本无法安装。
  6. 现在，在该磁盘上运行 xfs_repair 会产生有关坏超级块的错误和一些修复尝试，并将大量文件转储到 lost+found 目录中，但并没有修复我所希望的损坏文件。我将从备份中恢复此磁盘的所有信息，并重建其余部分（它保存了我的备份系统的目录，所以太糟糕了！）

所以我的问题是关于第二个用户卷（ext3 类型）。由于 xfs 卷发生的情况（即转储到 lost+found），我还没有尝试修复它。我有这个卷的部分备份，涵盖了最重要的文件，但如果能恢复所有其他文件（尚未损坏的文件），那就太好了。如果恢复的文件确实被转储到 lost+found，那当然比什么都没有要好得多。

我尝试 dd 它，但只输入了几 GB 就失败了（它是一个 500GB 的卷）：

dd if=/dev/sdf of=/homLocDump/sdfDump.img conv=noerror,sync 

dd: reading `/dev/sdf': Input/output error
15002344+0 records in
15002344+0 records out
7681200128 bytes (7.7 GB) copied, 493.416 seconds, 15.6 MB/s
dd: writing to `/homLocDump/sdfDump.img': Read-only file system
15002344+1 records in
15002344+0 records out
7681200128 bytes (7.7 GB) copied, 493.417 seconds, 15.6 MB/s

fsck 显示：

[root@shank ~]# fsck.ext3 -nv /dev/sdf
e2fsck 1.39 (29-May-2006)
Couldn't find ext2 superblock, trying backup blocks...
fsck.ext3: Bad magic number in super-block while trying to open /dev/sdf

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>

我尝试使用“-b”选项，使用块 8193、16384 和 32768，然后为 4k 块 fs 使用更多超级块（我假设它和该系统中的其他设备一样是 4k 块大小）但得到的结果相同。

dumpe2fs：

[root@shank ~]# dumpe2fs /dev/sdf
dumpe2fs 1.39 (29-May-2006)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdf
Couldn't find valid filesystem superblock.

我还能再尝试在这个卷上运行 fsck 吗？除了超级块问题之外，我现在不确定在 raid 卷上运行 fsck 是否合适。

是否可以暂时替换 RAID 中的旧缺陷驱动器以获得可以安装卷的状态并恢复一些文件？

另外，我很好奇卷在 RAID 中怎么会这样损坏 - RAID 不应该保护完整性吗？如果 RAID 6 中有两个驱动器发生故障，难道它不应该容忍这种情况吗？

答案1

我认为很明显您的阵列基本上已经发生故障，除非您有备份，否则您的大量数据将丢失。如果您有备份，请更换所有发生故障的驱动器并从备份中恢复。如果您没有备份，并且您的雇主认为这是值得的，请让专业的数据恢复公司尝试恢复他们能恢复的数据（看在上帝的份上，不要再对这些驱动器做任何事情，因为您只会让情况变得更糟），但这是一个相当昂贵的选择。

此时，除了进行备份和/或让专业人员尝试恢复数据之外，您能做的最好的事情就是设置监控系统和流程，以确保不会再次出现阵列故障，方法是在驱动器发生故障时进行更换，而不是等到为时已晚且太多驱动器无法恢复所有数据后再进行更换。

我也会认真考虑换个工作。环境恶化到这种地步简直就是地狱。

答案2

此时，很明显您的卷已丢失。您现在需要做出决定：您有多需要这些数据？

  • 如果您有时间并且不介意进一步丢失数据，请随意继续尝试。

  • 如果您急需它，请关闭整个阵列。在驱动器的当前位置上做标记。还要标记重建过程中移除的驱动器的来源。致电 OnTrack 等数据恢复专家，安排将阵列寄给他们进行恢复。

  • 如果您不需要这些数据，我建议您从备份开始。但请确保您更换了所有返回错误的驱动器。在此期间，请查看所有驱动器的 SMART 日志，并更换错误较多的驱动器。您可能需要删除现有卷。

从长远来看，我建议重新配置您的阵列。RAID5 或 RAID6 配置中的 16 个驱动器太多了。我建议将您的驱动器分成两组，每组 8 个运行 RAID6，并在这些驱动器上运行 RAID0。JetStor 可能会自动为您执行此操作，并可能将其称为 RAID60。

相关内容