free way to backup ESXi VM's

If you find yourself in the position that your (small) company has neither the funds to:
A) license ESX over ESXi

B) license a remote agent for Backup Exec to do backups of your ESX host

Then you have to consider alternative ways of backing up your VM's.
I would definitely recommend storing your VM's on an NFS share (as opposed to iSCSI) because it allows you opportunities to do file-level backups instead of block level backups. 

If you have Backup Exec and live in a Windows Server centric environment, you might consider
using an NFS share on a Server 2008 R2 host. Backup Exec comes with Remote Agent for Windows licenses  and can use VSS (volume shadow copy services) to make a snapshot of the drive that your NFS share is on and copy the NFS folder. The assumes you have already had a copy of Backup Exec (tested using 2011 R3 and it was fine) or some other backup software that takes advantage of VSS.
 
If you don't have Backup Exec or similar VSS using software, your only free option (that I'm aware of) is to use Solaris/Opensolaris/Openindiana. ZFS snapshots and clones make it (relatively) easy to write bash shell scripts you can schedule with crontab to easily do full/differential backups with rsync. The destination of the backups is pretty flexible as well, as you can easily mount an NFS or Windows share on your backup fileserver from Opensolaris or Openindiana. (If your company doesn't have budget for Backup Exec likely you are using Openindiana because its free for commercial use.)

If you are backing up a ZFS volume (filesystem in Openindiana) to another ZFS volume on another Openindiana server, differential backups are straightforward. You can use the --update option in rsync and it will only backup those VM files that have actually changed. If your VMDK files contain a lot of empty space (pre-allocated vs sparse) then the --compress-level=1 option in rsync works great (for Openindiana to Openindiana, don't expect it to work cross platform, it didn't for me). Cuts down on your network traffic if there is not a dedicated connection between servers.

Another option (on top of the above) is to compress the VM's server side BEFORE transferring them to the backup destination. This also helps to cut down on network traffic (we have a half gigabit half 100Mbit network and not all destinations are on the same switch so a big help here.) I'll detail using LZO compression in the next post.