I have had this work before, but I'm sure there are others who wouldn't recommend it.
We're running ESXi and don't have servers that are necessarily 24/7 critical. I shut down the VM, then using the disk storage browser, copy the directory to a storage NAS and then 7zip the directory into one large 7z file (and verify there aren't any errors). This takes a LOT of time to copy over, but for us it works. If something goes wrong I can copy the VM back over to the ESXi server and point a new VM configuration there to fire it back up. Be aware that you may have to be careful about things like MAC addresses and such being "duplicated" if you're restoring; we do this primarily in case there's a failure of the VM server. Use MD5 sums to verify your large backup file when transferring it to make sure it's not corrupted in storage or transfer.
Another option is to treat your VM as a regular server and make full backups to your backup server. If there's a failure, spin up a new VM and do a "bare metal" restore on the virtual computer. This saves you having to have special storage set aside just for the virtual machines, which can easily grow to several gig each and the larger the file, the greater the chance that it'll get corrupted. This is probably a better solution in many cases because it eliminates variables with version of VMWare (your backup is one version, you upgrade VMWare or change something and forget, suddenly your backups are screwy...)
Your last option would probably be to get VMWare-specific backup solutions that are ESX-aware. Expensive as all get-out, but they're aware of the issues involved in file locking and access for the virtual disks, and you won't need to shut down the VM's to do the backup. Attempting any copying or modifications while it's running results in Bad Things(tm).
I've read that there are issues with using a VM that has snapshots and just copying files over as a "Backup" (my first suggestion), so I don't use snapshots in VMWare. I can't confirm the issues though.