服务器 Gind.cn
  1. 服务器 Gind.cn
  3. RAID上的卷失败 – 如何处理？
Intereting Posts
RDP证书分发点 灵活的教室环境（OS，Office） Ubuntu的服务器 – 我需要做什么来保持它uptodate 有没有一种方法可以将长时间运行的任务排队？ 有没有像WinDirStat的RedHat程序？ 与接口统计工具不同，哪些数据不可用于tcpdump？ 什么是SQL Server 2008的推荐备份计划 使用Azure进行应用程序性能testing 在Centos5.8上安装jdk7u7 阿帕奇在符号链接上的行为奇怪 Ansible group_vars对非群组成员可见 新的RHEL5和旧的Solaris 8之间的远程X-windows Java 7或8需要运行.Jar（Linux） exim重写主题行如果回复到域不匹配从域 通过SSH的Intranet

RAID上的卷失败 – 如何处理？

我有一个最近接pipe了RAID的情况，真的可以使用一些build议。 我希望我没有把它搞糊涂了。

我正在pipe理的ad-hoc集群上的一对服务器开始报告磁盘问题。我在另一个上运行fsck，xfs_repair。 第一个似乎是固定的，第二个没有报告问题。 他们可以挂载读写，并会给某些文件读取错误。

我将磁盘追溯到单个RAID：

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

查看JetStorpipe理界面：

  • 两个驱动器被列为失败
  • 6个驱动器列为缺陷
  • 三个用户卷被列为失败（其中两个比另一个更重要）

以下是我所做的：

  1. 将所有分区重新挂载为只读或卸载它们。 （即使JetStor支持说这不是必要的，该单位已经过保修，但他们回答了这个问题）
  2. 更换（热插拔）两个失败的驱动器，让他们重build。
  3. 更换（热插拔）两个标有“缺陷”的驱动器，让他们重build。 这两个驱动器与JetStorpipe理面板中两个更重要的失败用户卷相关联。
  4. 创build了几个新的用户卷，以充当更大的replace卷并充当中介存储。
  5. 试图重新安装两个失败的卷。 现在他们根本不会挂载。
  6. 现在运行xfs_repair就会生成关于坏超级块和一些修复尝试的错误信息，并将丢失的+find的目录转储到大量的文件中，但是并没有修复一个我一直期待的错误。 我要从备份中恢复这个磁盘的function，并重新构build其余部分（它包含我的备份系统的目录，所以很好！）

所以我的问题是关于第二个用户量（typesext3）。 我还没有尝试修复它的b / c发生了什么xfs卷（即转储丢失+find）。 我对这个卷的部分备份覆盖了最重要的文件，但是将所有其他文件恢复（还没有被破坏）会很棒。 如果恢复的文件确实被丢弃+find了，那当然会好得多。

我试图dd，但是这只是一个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块（我假设它是像这个系统中的其他设备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是否合适。

是否有可能暂时replaceRAID中的旧的缺陷驱动器来获得卷可以挂载的状态并恢复一些文件？

另外，我很好奇在一次突袭中，这样一个卷可能会变坏，不应该保护这个完整性吗？ 如果两个驱动器在RAID 6中失败，是不是应该容忍这个问题？

我认为你的arrays基本上是失败的，除非你有备份，否则很大一部分数据会丢失。 如果您有备份，则全部replace出现故障的驱动器并从备份中恢复。 如果你不这样做，而且你的雇主认为这是值钱的话，那么请一个专业的数据恢复公司试着恢复他们所能做的（为了上帝的爱，不要再用这些驱动器做任何事情，因为你只会让事情变得更糟） ，但这是一个相当昂贵的select。

在这一点上，除了进行备份和/或让专业人员尝试恢复数据之外，您可以做的最好的事情是设置监视系统和进程，以确保您不会再次遇到失败的arrays，通过更换驱动器，而不是在太迟之后，太多无法恢复所有的数据。

我也认真考虑在别处工作。 一个被允许腐化成这种状态的环境是一个特别的地狱。

在这一点上，很明显，你的卷丢失了。 你现在有一个决定： 你需要这个数据有多严重？

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

  • 如果您需要这么做，请closures整个arrays。 在当前位置标记驱动器。 还要标记在重build过程中移除的驱动器及其来源。 致电像OnTrack这样的数据恢复专家，并安排将数组发送给他们进行恢复。

  • 如果你不需要这些数据，我build议现在是时候从备份开始。 但是请确保您replace了所有已返回错误的驱动器。当您处于这种状态时，请查看所有驱动器的SMART日志，并更换比其他错误更多的错误。 您可能需要删除现有的卷。

从长远来看，我build议重新configuration你的arrays。 RAID5或RAID6configuration中的16个驱动器太多了。 我build议将驱动器分成两组，每组8个运行RAID6，RAID0通过这些驱动器。 JetStor可能会自动为您执行此操作，并可能将其称为RAID60。