我只是想知道，当使用 Windows Server 作为文件服务器时，人们如何处理持续的文件系统稳定性，而无需使系统脱机以执行 chkdsk /f 或 chkdsk /r？显然，人们并不希望文件服务器不可用……而且文件服务器现在有如此多的存储空间，以至于运行 chkdsk 可能需要几天时间……那么您如何保护数据免受损坏？
答案1
微软已经发布了运行 checkdisk 时提高性能和减少停机时间的指导意见：
NTFS Chkdsk 最佳实践和性能
https://www.microsoft.com/downloads/en/details.aspx?FamilyID=35a658cb-5dc7-4c46-b54c-8f3089ac097a
特别值得注意的是：
卷大小对性能没有影响。
对于包含大量文件（数亿/数十亿）的卷，为 chkdsk 利用更多内存可以显著提高性能。
Windows 2008 R2 chkdsk 的性能是 Windows 2008 的 2 到 5 倍。Windows 2003 太糟糕了，他们可能不好意思公布统计数据。
您应该在计划重启之前主动检查卷是否脏污。这可以帮助减轻意外的数小时启动延迟的影响。
文档中没有提到，但强烈建议这样做：使用多用途文件服务器来为数亿个文件提供服务会增加崩溃的概率，并且卷将被标记为脏。应采取措施确保不会发生崩溃。一个例子是不要将文件服务器用作打印服务器（打印机驱动程序在蓝屏领域有着悠久的臭名昭著的历史）。另一个例子是“文件归档软件”。强烈建议使用具有延长运行时间的备用电源。
答案2
我认为 chkdsk 不是执行预防性维护的工具。如果您必须定期运行 chkdsk 来纠正问题，那么您就有一个需要解决的潜在问题。
答案3
我维护的文件服务器中大约有 7TB 的一般用户数据。这 7TB 主要是办公类型的文件，所以数量有数百万。我没有确切的数字，因为获取数据需要很长时间，但在我们的 Server 2008 故障转移群集的各种文件系统中大约有 700 万到 1200 万个文件。
除修复问题外，我们从不运行 chkdsk，并且我们从不进行碎片整理。
NTFS 现在已经具备足够的自我修复能力，因此我们很少遇到问题。当我们遇到问题时，通常是由于存储系统基础设施出现某种故障；自发光纤通道阵列控制器重新启动、FC 交换机崩溃并重新启动，诸如此类。从服务器背面拔掉电源完全可以避免这种情况。
事实上，我们最近经历了一次灾难性的 UPS 故障。整个房间同时严重瘫痪。NTFS 几乎毫无征兆地恢复了，而且无需运行 chkdsk。
关于碎片整理...我们的 FC 磁盘阵列中有 48 个驱动器，由于它是 HP EVA，因此条带随机分布在各个主轴上。这意味着，就驱动器而言，即使是大量顺序访问实际上也是随机的，这进一步意味着，顺序性较高的文件系统的性能至少比碎片化程度较高的文件系统好。因此，常规碎片整理对大量 I/O 开销几乎没有帮助。
至于预防性维护，NTFS 现在已经足够自动化，几乎可以自行完成所有工作。偶尔我会运行 chkdsk处于只读模式看看是否值得以完整模式运行它。到目前为止，它在我们的集群上尚待. 即使在我们的 2TB、400 万个文件 LUN 上，它也可以在不到一天的时间内运行。
也就是说，您可以做出一些架构决策，以帮助减少最终对离线 chkdsk 的需求，并在您需要执行时加快速度：
- 将 RAID/SAN 控制器上的缓存策略设置为不缓存写入。然而，这就是电池备份缓存存在的原因，因此性能受到影响这将导致不需要采取。但这是防止离线 chkdsk 的首要措施。
- 保持 LUN 较小。文件数量比大小更重要。一个装满 Ghost 映像的 6TB LUN 比一个装满 6KB 文件的 512GB LUN 检查速度快得多。
- 保持足够的自由空间。基于完全主观标准的经验法则是任何时候自由空间不得少于 15%。
- 如果您的数据允许，请使用大于 NTFS 默认 4KB 块大小的块大小。在对我的文件进行一些统计后，我发现我可以对我的大多数文件系统使用 16KB 块。块越大意味着要检查的块越少，并且还允许存储子系统更好地利用预读。是的，小文件会占用更多空间，但在我们的卷上，它只会增加总大小的 4% 左右。
答案4
在我之前工作的地方，我们使用 Tripwire。有关更多信息，您可以在此处查看：Tripwire 文件完整性管理器
您还可以在这里找到市场上文件完整性检查解决方案的概述：文件完整性检查器