Ok. I'll get it and post it for you.

It's not from a specific distro, though it was compiled on Slackware-11.0, though I doubt that specific version matters.

It is a completely standard rsync-3.0.3 built from source.

The only things you need to do to build it yourself if you don't want to trust a binary from some random person on the net:

1. Build statically. Your libraries are not going to be around on the target ESX box.

2. Build without TLS support. The mgmt kernel doesn't do TLS, so your binary cannot either.

3. Optional: strip the binary when done.

To use this:

1. All of this is unsupported. Take responsibility for your own actions.

2. Enable unsupported sshd to your ESXi system.

3. Place this 'rsync-static-stripped' binary into /bin or somewhere else in your path on your ESXi system.

4. You will probably want to rename this binary to just "rsync", so that you don't need to specify it on the commandline.

Note that you should probably not try to rsync any files that are currently in use. 

There is no warranty and no guarantees of any kind.

Interesting Glin, have you tried a new build of NFS in the same way as rsync?  May be able to get past the slow export to NFS share.

Hi Shahid

I was seeing real slow write speeds to my NFS share, however I've been doing some tests and seems that if I export the share with the switch 'async' I get decent speeds - it was 'sync' before.  Funny how this doesn't affect ESX. 

Thanks for the helpful insight Shahid.  Thinking back you setup an NFS share on ESXi and ESX totally differently, or well I did.  I'm just glad I'm getting decent speeds now

thanks BThunderW.....that did the trick.

Thanks glim, I did this and it works great.  However, the rsync binary in /bin disappears on reboot.  I am guessing the root filesystem in ESXi is a ramdisk that gets created from a compressed image file on each boot.  Did you experience this as well?  Any thoughts on a workaround?  I doubt updating the contents of the image file ESXi is using to include the binary would be easy.

Oh, wait, there they are, in /vmfs/volumes/Hypervisor1.  Just tar files...I guess that wouldn't be that difficult after all.

But, more than I want to mess with.  I ended up making a bin directory in /vmfs/volumes/datastore1 and putting rsync in there so it will persist across reboots, then added "--rsync-path=/vmfs/volumes/datastore1/bin/rsync" to the rsync command on my remote system that initiates the copying.