小编the*_*age的帖子

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