What sort of corruption are you seeing and how are your destinations connected - RDM, NFS, CIFS, etc.?
If you're having difficulties with the remote destination, the chances are that it's the nature of the connection which is the issue for at least some of the problems you're having. I guess you might see the same sort of problems if you were running a VM with an attached disk mounted on a remote datastore - which is probably not recommended due to latency issues.
Personally, I'd recommend looking at your VMs and how they organise their data. See if you can split your VM into two VMDKs, one for the O/S and the other for data - that way, you can use VDR to backup your VM's O/S partition and use your VM O/S backup application (e.g. in Windows Server) to backup your data locally and remotely. As an alternative, and where an agent-based solution is preferable, consider a commercial application as mentioned by the previous poster.
Please award points if you find my answer helpful 
phykell wrote:
What sort of corruption are you seeing and how are your destinations connected - RDM, NFS, CIFS, etc.?
If you're having difficulties with the remote destination, the chances are that it's the nature of the connection which is the issue for at least some of the problems you're having. I guess you might see the same sort of problems if you were running a VM with an attached disk mounted on a remote datastore - which is probably not recommended due to latency issues.
Personally, I'd recommend looking at your VMs and how they organise their data. See if you can split your VM into two VMDKs, one for the O/S and the other for data - that way, you can use VDR to backup your VM's O/S partition and use your VM O/S backup application (e.g. in Windows Server) to backup your data locally and remotely. As an alternative, and where an agent-based solution is preferable, consider a commercial application as mentioned by the previous poster.
Please award points if you find my answer helpful
Hi
The connection is being done by NFS. its a short travel time ni the order of 11-15ms its a monitored server and my ISP tell me they are seeing no errors on the line. I manage the routers at the end and I see no errors on the line!
he disk becomes unusable until integrity check is run, again and again and again.
Yes the recommendation would (should) work, so should VDR. I really don't want to have to go to all this extra work to simply make it work.
So atleast in my book VDR should be used for any real sort of backups (atleats where you want to be able to sleep at night). Fix it up VMWare, good start.
This has been my experience so far. Of to try out VEEAM
...so you've got a VMDK deployed on a remote NFS volume? What's your bandwidth like and is your latency fairly consistent or is it variable? Are you seeing any specific error messages reported by VDR? A VMDK is not usually connected to a server over a WAN connection and for good reason - they are notoriously unreliable for replication tasks where data integrity is critical, and a simple ping value isn't really going to give you the level of detail you need to properly evaluate the suitability of your connection. Can you be absolutely sure that there are no service interruptions on your WAN line? Are you using any firewalls?
While VDR certainly does have some issues, I think any problems supporting a remote VMDK destination are due to vSphere because it's just not an anticipated configuration. An ESXi server will generally expect an attached datastore to be presented on a SCSI interface or a local network at Gigabit speeds.
Good luck with Veeam
