我们需要定期通过我们的广域网（英国到美国）在50Mbps租用线路上传输大型（60GB）Hyper-V虚拟机映像。 我们也在网站之间使用DFS-R。 从历史上看，我使用7-zip将虚拟机压缩成更小的100MB块，然后将这些文件放到DFS-R传输文件夹中。 当积压清除时，在另一端解压缩。
我想知道是否浪费了我的时间，也可能把整个VM（主要是VMDX文件）放在传输文件夹中，让DFS-R在传输过程中对其进行压缩。
所以问题是 – 与7-zip的原生7z格式相比，DFS-R压缩algorithm的效率如何？ 7-zip将图像压缩到20GB左右，节省70％。
我感觉到，在7-zipalgorithm中，打包和解包的额外时间超过了任何可能的更高的压缩比率。 也就是说，传输100MB块的感觉比一个大的50GB的VMDX文件“更好”。
DFS-R使用称为远程差分压缩的东西。
该algorithm不是比较和传输整个文件，而是比较源和目标副本之间的顺序数据块的签名。 这样，只有不同的数据块需要通过networking传输，才能在目标位置“重build”文件。
因此，RDC与7-zip中使用的压缩algorithm没有真正的可比性。 虽然他们使用相似的技术（在数据范围内构build签名字典），但是7-zipalgorithm被devise为将字节重新排列成无损容器格式，其中所有数据被“挤压”在一起，其中RDC的目的是识别类似文件之间的差异或文件版本，以便最小化传输的数据量，以保持副本同步
如果在目标位置已经有类似的VMDX文件，则不需要将文件拆分为100MB块。 只要确保在压缩图像时总是使用相同的压缩algorithm
这种行为（比较类似的文件 ，而不是相同的文件的不同版本，并提取块）被称为“跨文件RDC”，公众可用的文档是相当稀less，但AskDS博客团队有一个简短的，但很好的澄清这个问答post
正如Mathias已经指出的那样，DFS-R采用类似于rsync的 “远程差分压缩”algorithm ，只传输已经存在于远程端的文件的改变/附加部分。 此外，自从Server 2003 R2中首次出现DFS-R以来， 数据在传输之前使用XPRESS压缩algorithm进行压缩 （参考： Technet博客 ）。 我找不到使用XPRESS的实际变体的任何细节，但由于压缩必须在运行中发生，因此可能使用LZNT1 （基本上LZ77降低了复杂性），因为这是在NTFS中用于相同的目的。
如果要监视压缩比率，请考虑启用DFS-Rdebugging日志logging并评估日志文件。
任何EXPRESSalgorithm的压缩率都可能比使用7zip的压缩率要低（甚至可能高达2倍），而7zip的优化algorithm是为了减小文件大小，而不是减lessCPU使用率。 但是，再次使用RDC（只允许传输文件的变化部分），您可能会比20 GB归档中的数据less得多。
预先创build一个使用RDC传输的7zip压缩文件，看起来像是一个好主意，可以获得两全其美的效果 – 只传输更改，但对于更改的部分压缩比更高 – 但不是。 压缩会破坏整个文件，甚至在数据stream开始时更改单个字节会导致压缩文件看起来完全不同于以前。 有压缩algorithm的修改，以缓解这个问题 ，但7zip似乎并没有实现他们到目前为止。
总而言之，使用DFS-R传输文件修改时，您可能会显着节省通过networking传输的字节。 但是你不太可能得到任何时间的节省，而且你在目的地和源头上引发显着的I / O和CPU负载，因为在实际之前需要读取和校验和文件（源和目的地）传输可以开始。
编辑：如果你有新的文件，RDC确实没什么帮助 – 没有对应rsync的--fuzzy参数，它会在目的地寻找类似的文件，并把它们作为差分传输的基准。 如果你知道你有一个类似的文件（例如传输的VM HD的基准映像），你可以用这个文件预先设定目标目录。