我有以下设置：
我有一些客户使用“使用标准 Windows API 编写的读写”软件，这些软件正在读取和写入 Windows 服务器文件。这些客户都是 Windows 10 计算机，他们都在使用 Solidworks 的一款名为 PDM 的保险库软件。
该服务器是运行 PDM 服务器软件的 Windows 2016 服务器。
基本工作流程是用户在本地处理文件。当他们将文件签入保管库时，文件会从硬盘传输到服务器软件。服务器重命名文件并将其保存到文件夹中。由于我无法访问代码，因此无法确定具体操作方式。我认为重命名是为了防止用户自己“弄乱”文件，因为文件存储在一个神秘的文件夹和文件命名结构中。
我们发现文件在将来的某个时间点加载时会偶尔损坏。所有这些“损坏”的文件似乎都可以通过繁琐冗长的手动加载程序“保存”。由于这个问题是我的数据保险库，我希望追踪这个问题。
据保险库支持人员称，“95% 的时间这些问题都出在服务器或网络上，而不是保险库服务器软件上”。
你们网络管理员知道有什么方法可以反复尝试从客户端/服务器读取和写入文件，以测试通过网络读取和写入文件的问题吗？我的想法是运行一个客户端/服务器，多次传输文件并检查哈希值或类似的东西。
答案1
检查网络上的文件传输：有一个 MS 文件服务器和两个客户端（这样客户端可能的本地缓存不会妨碍您的结果）。
在客户端机器 #1 上，生成文件（内容随机？），并将它们保存到服务器。同时，为每个测试文件计算校验和（比如 md5sum？），也许只是将校验和逐行附加到同一服务器上的“校验和移交索引文件”中。
在客户端机器 #2 上，逐个从服务器加载文件，并计算校验和。实际上，您可以对映射网络共享上的每个文件（来自客户端 #2 机器）运行校验和工具（例如 md5sum）。然后将校验和与源机器生成的校验和进行比较。
这只是一个基本想法。您需要编写一些脚本来自动执行检查，并让它们运行一个周末左右。如果位腐烂不是立即发生，而是发生在磁盘驱动器上，那么这种快速检查可能什么也发现不了。
如果您遇到特定示例/数据损坏事件，是否有办法获取原始文件和损坏文件（它们应该是相同的）？这些文件是什么格式？这是机器可读的文本文件（例如 XML）还是二进制文件？也许可以比较内容，以准确了解损坏情况。损坏的性质可以提供进一步的线索，说明损坏可能来自何处。
除了对 ASCII 文本起作用的经典“diff”之外，我记得有专门用于二进制比较的工具。
此外，存储服务器是否运行备份？详细信息取决于备份方案，但关键是，如果旧的服务器端备份包含一个健康的文件，而服务器上的当前文件已损坏，那么这可能会缩小您的问题范围。并且推断这个备份主题，如果设置存在数据损坏问题，并且没有实施万无一失的备份方案，您的组织还有什么理由需要解决此问题？
即使您不再拥有健康的原始文件：如果损坏的文件最终被解析它的软件拒绝，那么获得更详细的调试日志、查看解析器停止的位置、文件不再“格式良好”的位置将是很好的 - 但我知道在封闭文件格式的封闭源软件中您通常没有这样的机会。
人们说这正是企业存储硬件的目的，它在整个“信号链”上维护“完整性元数据”——即现代版本的 SCSI 和派生的互连技术（FC、SAS）以及相应的旋转锈蚀类，不确定是否有具有这种功能的 SSD。与其提供具体的指示，我建议您向 Google 询问有关 Linux 中数据完整性的问题。很有可能这正是硬件层面困扰您的问题。您对服务器中的底层存储子系统了解多少？
尽管这种可能性很小，但如果你通常无法打开老的文件：处理文件的应用程序软件是否已更新？这可能是应用程序更新破坏了与旧数据的兼容性的情况吗？如果您没有整个文件的备份，您是否可以安排在某处记录校验和，以及文件名、大小和时间戳，以查看 6 个月后检索的文件是否相同或不同？
通过“繁琐的手动加载程序”来挽救——那到底是什么？一些恢复算法在损坏的文件上起作用？还是只是从相应的旧备份中检索完好的原始文件？无论哪种情况都可能发现问题的更多本质：要么您可以将损坏的文件与完好的原始文件进行比较，要么了解“恢复”过程实际上对“损坏”文件做了什么。