Windows Server 2008 Software Raid 5 - 数据完整性问题

Fop*_*ush 5 windows-server-2008 software-raid raid5

我有一台运行 Windows Server 2008 R2 的服务器,带有(Windows 原生)软件 raid-5 阵列。该阵列由 7 个 1TB 西部数据 RE3 和 RE4 驱动器组成。我有这个阵列的离线备份。

问题是这样的:几天前,我在将一个大文件复制到磁盘后注意到该文件存在完整性问题——我通过 uTorrent 下载了一个大约 12GB 的文件。将其移至raid 阵列后,我使用uTorrent 重新定位下载位置,并执行重新检查,以便我可以从该位置为其播种。复查发现复制文件只有6308/6310块完好无损。

我的下一步是编写一个快速的 powershell 脚本,将文件复制到数组,同时对原始文件和结果文件执行 SHA1 哈希并比较它们。较小的文件(100-1000MB)复制就好了。当我开始复制更大的数据(~15GB)时,我发现哈希检查失败了大约 2/3 的时间。损坏的文件有非常非常小的不一致 - 小于 0.01%(编辑 - 后来的实验表明,损坏的数据块的长度始终为 60 个字节,每个 15GB 复制文件通常会出现一到三个。损坏的数据出现随机,没有一致的翻转位模式)。我通过将这个大文件放在服务器的 C:\ 上,并从那里反复复制到阵列,进一步消除了网络或客户端问题的可能性,看到了类似的结果。

通过资源管理器、powershell 或标准 Windows 命令提示符复制数据会产生相同的结果。没有任何副本失败或报告任何问题。RAID 阵列本身在磁盘管理中被列为正常。

经过几次实验,我关闭了服务器并在一夜之间运行了 memtest。没有检测到错误。chkdsk 的基本运行没有发现任何问题,但我没有使用 /R 标志,因为我不确定这会如何影响软件 raid-5 卷。

我接下来运行 Crystal Disk Info 来检查驱动器上的智能数据 - 但发现 CDI 仅检测到阵列中 7 个磁盘中的 5 个。我不知道为什么。尽管如此,CDI 在单个驱动器上显示以下“警告”标志:

05 199 199 140 000000000001 Reallocated Sectors Count
C5 200 200 __0 000000000001 Current Pending Sector Count
Run Code Online (Sandbox Code Playgroud)

这有点令人担忧,但我真的不知道如何处理这些信息。我几乎不觉得一个重新分配的部门会导致这种情况。

在这一点上,我正在寻找有关下一步该做什么的一些指导。我需要确定此问题的原因,但我对运行 chkdsk /R 或任何可启动磁盘运行状况检查程序犹豫不决,因为我担心它们可能会破坏阵列。我已经考虑过触发阵列的重新同步,但我实际上不确定如何做到这一点,而不会做一些愚蠢的事情,比如手动删除磁盘然后恢复它。

任何可以帮助我找出此问题的确切原因的建议将不胜感激。

the*_*bit 3

由于您正在执行的任何操作都没有失败,因此运行chkdsk /R可能不会产生任何结果 - chkdsk 将无法恢复任何未检测为损坏的内容。

像您所看到的那样的数据损坏有几个可能的来源:

  1. 写入数据之前软件 RAID 算法执行中的位翻转
  2. 写入数据时硬件实现中的位翻转
  3. 磁性介质上的位翻转
  4. 读取数据时硬件实现中的位翻转

您应该选择一种有条不紊的方法来排除您可以排除的内容:

  • 数字 4 - 读取时的位翻转 - 应该很容易识别,因为翻转会发生在不同的数据区域,因此当您尝试在大文件上计算它们时,md5 或 sha1 哈希值会不时发生变化

  • 第三点 - 磁性介质上的翻转 - 不太可能未被检测到,因为每个硬盘都包含前向纠错算法以及错误检测校验和,并且您肯定会看到不可恢复的扇区读取错误,其数量级比位翻转滑动要多几个数量级通过 - 查看 SMART 不可恢复的读取错误应该足以排除这一错误

  • 第二——这个可能很难被发现。尽管 SATA 协议通过纠错算法保护传输的数据,其中第 3 种情况的逻辑将应用并在让翻转的位扇区通过之前将任何传输减慢到爬行速度,但损坏可能发生在其他地方并且未被检测到 - 在缓冲区中例子。

  • 第 1 点——我认为这是最有可能的情况。实现中的错误或者(更有可能的是,操作系统发布 4 年后其他地方可能会注意到并记录这种重要的错误)硬件故障(例如有缺陷的 RAM)可能会导致这种位翻转。执行几次内存测试以排除 RAM,尤其是在您不使用 ECC 内存的情况下。在具有相同软件配置(最好是系统映像)的类似环境中重新运行测试,以排除基于软件的原因。

您还可以将测试扩展到复制 15 GB 的较小文件,只是为了看看在写入一定量的数据后损坏是否也会影响其中一个文件。如果是这种情况(根据您的描述,这似乎很可能),您应该假设已放置在磁盘上的数据也发生了类似的损坏 - 尝试与原始数据或已知良好的加密哈希值与较大文件进行比较,以估计损坏程度。

此外,如果能够重新计算 XOR 校验和并将其与存储在磁盘上的奇偶校验数据进行比较,那就太好了,大多数 RAID 5 系统都提供这种通常称为“清理”的功能。对于 Windows,似乎没有办法开箱即用地执行此操作。我只能找到为您执行此操作的数据恢复服务。

狩猎好。