碎片导致 vhdx 备份大小过大

Question

服务器托管名为 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 块，如果是，是否可以更改？

Answer 1

最终，最直接的解决方案是添加自定义碎片整理任务，命令行参数指定“传统”碎片整理。这将数千个片段合并为连续的文件，这反过来又让 vhdx 图像避免了由于其 2MB 块大小而不得不包含片段之间的所有空白空间。最终导致问题的服务器软件被淘汰并由软件提供商托管的门户网站取代。于是问题的根源就没有了。碎片整理任务对于保持小型服务器的优化仍然很方便，所以我把它留在了那里。

我从来没有找到数据库文件像这样碎片化的原因。我从软件供应商那里得到的反馈说他们没有收到任何其他类似的报告。它没有解决导致这种碎片模式的行为的问题，而是专注于备份方法，建议不同的备份格式（因此不同的备份软件），或更改 WSB 在创建 vhdx 容器时选择的 BlockSize（但没有这样的选择是可用的）。所以没有任何帮助或信息。我对正在发生的事情有一些猜测，从尝试手动实现稀疏文件到尝试对齐其数据以让驱动器磁头更好地寻找。这两个听起来都很奇怪，但是自 1990 年以来一直在开发如此庞大的企业软件

至于为什么内置的 Windows 'Defrag' 任务实际上并没有对驱动器进行碎片整理......好吧，它曾经是，但是对于 Server 2012 和更新版本，Microsoft 决定默认运行传统的碎片整理不再实用，因为服务器存储容量不断增长。据推测，服务器操作员会知道是否有任何分区需要传统的碎片整理，并会定义一个自定义任务来处理它。我没有意识到这种变化。内置任务的命令行从未包含实际的 /D 参数并没有帮助 - 当没有指定任务时，它依赖于默认行为。新的 Windows 版本包括附加参数，这些参数覆盖了默认行为。如果一个人只是在寻找被删除的参数，这种事情就更难发现。