是否有人在ESXi中使用rsync实现了真正的差异同步？

稍后我在使用服务控制台在ESXi中执行任何操作这一事实令我感到rate惜...

我有一个可以在ESXi 4.1U1中使用的工作rsync二进制文件（v3.0.4）。将VM或备份从一个本地数据存储复制到另一本地数据存储时，我倾向于在cp上使用rsync。我已使用rsync将数据从一个ESXi盒复制到另一个ESXi盒，但这仅用于小型文件。

现在，尝试在我的主要ESXi计算机和辅助ESXi计算机之间通过ghettoVCB进行备份的真正差异同步。但是，即使我在本地执行此操作（从一个数据存储到同一台ESXi机器上的另一个数据存储），rsync仍会完整复制文件。我有两个总计80GB的VMDK，而rsync仍然需要1到2个小时之间的任何时间，但是VMDK并没有每天增长那么多。

以下是我正在执行的rsync命令。我在本地复制，因为最终这些文件将被复制到从远程系统上的LUN创建的数据存储中。它不是远程系统上的rsync守护程序将服务的rsync。

rsync -avPSI VMBACKUP_2011-06-10_02-27-56/* VMBACKUP_2011-06-01_06-37-11/ --stats --itemize-changes --existing --modify-window=2 --no-whole-file
sending incremental file list
>f..t...... VM-flat.vmdk
 42949672960 100%   15.06MB/s    0:45:20 (xfer#1, to-check=5/6)
>f..t...... VM.vmdk
         556 100%    4.24kB/s    0:00:00 (xfer#2, to-check=4/6)
>f..t...... VM.vmx
        3327 100%   25.19kB/s    0:00:00 (xfer#3, to-check=3/6)
>f..t...... VM_1-flat.vmdk
 42949672960 100%   12.19MB/s    0:56:01 (xfer#4, to-check=2/6)
>f..t...... VM_1.vmdk
         558 100%    2.51kB/s    0:00:00 (xfer#5, to-check=1/6)
>f..t...... STATUS.ok
          30 100%    0.02kB/s    0:00:01 (xfer#6, to-check=0/6)

Number of files: 6
Number of files transferred: 6
Total file size: 85899350391 bytes
Total transferred file size: 85899350391 bytes
Literal data: 2429682778 bytes
Matched data: 83469667613 bytes
File list size: 129
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2432530094
Total bytes received: 5243054

sent 2432530094 bytes  received 5243054 bytes  295648.92 bytes/sec
total size is 85899350391  speedup is 35.24

这是因为ESXi本身对VMDK进行了太多更改，以至于就rsync而言，必须重新传输整个文件？

有人真的实现了与ESXi的实际差异同步吗？

看来您只转移了2GB的增量更改。请记住，rsync仍然必须读取一个完整的文件并对其进行校验和，因此它必须读取80GB的数据。在rsync期间检查您的服务器统计信息。您在操作过程中是否绑定了CPU或IO？您可以从磁盘读取80GB文件的速度有多快？那将接近您的绝对最小传输时间。

还要注意的是，rsync在传输时会复制文件，然后在原子操作中将最终文件移到适当位置。您可以通过在目标目录中的传输过程中看到带有相似后缀的类似文件名来查看此文件。这意味着您必须读取160GB的数据（每个源和目标每个80GB）并在目标侧写出80GB。您是否看过--inplace选项？这可能是有益的。

简而言之，您可能只有2GB的更改，但是rsync正在处理很多工作。您可能会受到IO的约束，因为在同一磁盘上进行的所有读取和写入操作可能会导致大量争用和速度下降。

该线程很旧，但可能会对某人有所帮助。

由于ESX在每次写入新块时都锁定文件系统，因此性能并不是那么好，使用Option --inplace可能会获得更好的结果，但是请注意，如果取消同步，则文件不会保持一致更多。关于一致性，打开文件的rsync可能会不一致->在rsync之前更好地使用快照。

最好的问候马克

从外观上看，您正在使用进行本地到本地的复制rsync。在这种情况下，的默认行为rsync是关闭增量传输算法，然后执行“整个文件”传输。此默认行为的基本原理是，使用delta-xfer算法进行本地到本地传输通常比简单地复制整个文件要慢，因为delta算法涉及的CPU处理要比仅复制整个文件要多得多。

如果您认为使用delta-xfer算法将从本地复制到本地，则可以rsync通过指定--no-W（或--no-whole-file）选项来强制使用它。