我们需要通过 50Mbps 的专线定期在我们的 WAN（英国到美国）之间传输大型（60GB）Hyper-V 虚拟机映像。我们还在站点之间使用 DFS-R。以前，我使用 7-zip 将虚拟机压缩（压缩成较小的 100MB 块），然后将文件放入 DFS-R 传输文件夹中。当积压清除后，在另一端解压。
我想知道我是否在浪费时间，不妨将整个 VM（主要是 VMDX 文件）放入传输文件夹中，并让 DFS-R 在传输过程中对其进行压缩。
所以问题是 - 与 7-zip 的原生 7z 格式相比，DFS-R 压缩算法的效率如何？7-zip 将图像压缩到大约 20GB，从而节省了 70%。
我感觉打包和解包的额外时间比 7-zip 算法中可能的任何更高压缩率都重要。也就是说，传输 100MB 块感觉比传输一个 50GB 的大 VMDX 文件“更好”。
答案1
DFS-R 使用一种称为远程差分压缩的技术。
该算法不会比较和传输整个文件，而是比较源和目标副本之间连续数据块的签名。这样，只需要通过网络传输不同的数据块，就可以在目标位置“重建”文件。
因此，RDC 与 7-zip 中使用的压缩算法实际上无法相提并论。尽管它们使用类似的技术（在数据范围内构建签名字典），但 7-zip 算法旨在将字节重新排列为无损容器格式，其中所有数据都被“挤压”在一起，而 RDC 的目的是识别类似文件或文件版本之间的差异，以尽量减少传输的数据量，从而保持副本同步
如果目标位置已经有类似的 VMDX 文件，则无需将文件拆分为 100MB 块。只需确保在压缩图像时始终使用相同的压缩算法即可
这种行为（比较类似文件，不是同一文件的不同版本，并提取块）被称为“跨文件 RDC”，并且公开可用的文档非常稀少，但 AskDS 博客团队有一个简短但相当不错的澄清在此问答帖子中
答案2
正如 Mathias 已经指出的那样，DFS-R 采用了“远程差分压缩”算法如同rsync 的仅传输远程端已存在的文件的更改/附加部分。此外，数据传输前经过压缩使用XPRESS 压缩算法（参考：Technet 博客) 自 Server 2003 R2 中首次出现 DFS-R 以来。我找不到有关实际使用的 XPRESS 变体的任何详细信息，但由于压缩必须即时进行，因此它可能使用LZNT1（基本上是复杂度较低的 LZ77），因为 NTFS 中就是用这个来达到同样目的的。
如果您想监控压缩率，请考虑启用DFS-R 调试日志记录并评估日志文件。
任何 EXPRESS 算法的压缩率都可能低于（甚至可能低 2 倍），而 7zip 的算法针对文件大小进行优化，而不是降低 CPU 使用率。但使用 RDC 时，它允许仅传输文件的更改部分，因此您通过网络传输的数据量可能比 20 GB 的存档量少得多。
预先创建一个要使用 RDC 传输的 7zip 档案似乎是一个好主意，可以两全其美 - 只传输更改，但对更改的部分使用更高的压缩率 - 但事实并非如此。压缩会破坏整个文件，即使在数据流开头更改一个字节也会导致压缩文件看起来与之前完全不同。有压缩算法的修改可以缓解这个问题，但 7zip 目前似乎还没有实现它们。
总而言之，使用 DFS-R 传输文件修改时，您可能会显著节省通过网络传输的字节数。但您不太可能节省任何时间，而且您会在目标和源上产生大量的 I/O 和 CPU 负载，因为在实际传输开始之前，需要读取和校验两个文件（源和目标）。
编辑：如果您有新文件，RDC 确实帮不上什么忙——没有与 rsync--fuzzy参数相对应的参数，该参数会在目标位置查找类似文件并将它们作为差异传输的基准。不过，如果您知道您有一个类似的文件（例如，已传输的 VM HD 的基准映像），则可以用这个文件预先播种目标目录。