该服务器托管一项名为 MultiCash-Datenbank 的服务。它为每个用户保留两个缓存文件（SPASD32.SRC 和 SPASD32Z.SRC），这些文件的大小每天增长约 1MB。每天还会添加大量小型数据文件。我观察了我们的网络备份三个月，发现保存这些数据的分区的 vhdx 映像的大小不断增长，每天增长 300-900MB。在 1TB 分区上，7GB 的数据最终膨胀为 30GB 的 vhdx 文件，我不得不采取行动。
在我考虑运行 DiskView 之前发现的临时解决方案的时间顺序如下：
- 重新创建分区（来回移动文件以合并它们）
- 缩小分区（执行可用空间合并步骤）
- 将分区大小限制为 10GB（将图像大小限制为 10GB）
- 运行手动碎片整理（默认计划碎片整理什么也没做在 2012r2！)
因此，由于某些未知原因，这些文件的集群在磁盘上的布局非常不寻常：
每个 4k 簇与其他簇之间相隔约 256 个簇（1MB）的可用空间。此外，文件大部分时间都是交错的。这种模式一直持续到覆盖所有可用空间。然后，随着文件进一步增长，多个簇的组变得更加频繁。
不知道这种碎片是由服务本身的写入模式还是某些 ntfs 优化机制造成的。Fsutil 报告文件未标记为稀疏。Contig 报告说，在这个包含 7GB 数据的 10GB 分区上，大约有 3000 个这样的碎片（= 跨越 3GB 的空间）。如果磁盘映像过程在有数据时分配 1MB 块，这将是有意义的。我读到 vhdx 格式包含性能优化，所以这可能是其中之一。那么不幸的是，它会导致这种最坏的情况。
我也承认我完全错了，我的观察结果与实际原因无关。一个警告信号是膨胀的备份不会压缩到与优化的备份相同的大小 - 对于 100% 的大小膨胀，压缩数据会多出 25%。
所以最后，我对情况只有部分了解，以及一些糟糕的解决方法。我想问：是什么导致了这种碎片化，以及如何阻止它？Windows Server Backup 的 vhdx 格式真的使用 1MB 块吗？如果是，可以更改吗？
答案1
最终，最直接的解决方案是添加自定义碎片整理任务，使用命令行参数指定“传统”碎片整理。这将数千个碎片整合到连续的文件中，从而使 vhdx 映像避免由于其 2MB 的块大小而必须包含碎片之间的所有空白空间。最终，导致问题的服务器软件被退役，并由软件提供商托管的 Web 门户取代。因此，问题的根源已经消失。碎片整理任务对于保持小型服务器的优化仍然很方便，所以我把它留在那里。
我从未发现数据库文件如此碎片化的原因。我从软件供应商那里得到的反馈是，他们没有收到任何其他类似的报告。它没有解决导致这种碎片模式的行为问题，而是专注于备份方法，建议使用不同的备份格式（因此使用不同的备份软件），或更改 WSB 在创建 vhdx 容器时选择的 BlockSize（但没有这样的选项可用）。所以没有任何帮助或信息。我对发生的事情有一些猜测，从它试图手动实现稀疏文件到它试图对齐其数据以让驱动器磁头更好地寻道。这两种情况听起来都很奇怪，但对于自 1990 年代以来一直在开发的如此庞大的企业软件（并且 UI 仍然看起来如此），任何事情都有可能发生。
至于为什么内置的 Windows“碎片整理”任务实际上没有对驱动器进行碎片整理……嗯，以前是可以的，但对于 Server 2012 及更新版本，微软认为由于服务器存储量不断增长，默认运行传统碎片整理已不再实用。据推测，服务器操作员会知道是否有任何分区需要传统碎片整理，并会定义一个自定义任务来处理这个问题。我不知道这个变化。内置任务的命令行从未包含实际的 /D 参数，这没有帮助 - 相反，当没有指定任务时，它依赖于默认行为。新 Windows 版本包含其他参数，这些参数会覆盖默认行为。如果只是寻找被删除的参数，这种事情就更难发现。