I've setup a second Veeam server across our WAN. My primary Veeam server at our main hub is currently successfully running replica jobs and sending them across our WAN to a target location, in this case an Iomega NAS unit. For my second Veeam server, I setup an ran a job for a VM local on the same ESX host as my Veeam server. The job fails with the following error:
Building path for backup
can not create /vmfs/volumes/Iomega-NAS/VeeamBackup : No such file or directory
The Iomega NAS is setup and seen by my ESX host as a datastore. I can browse this Iomega datastore, and the top level folder is "VeeamBackup". This folder was initially created when I began running successful replica jobs from my primary Veeam server. Not sure why second Veeam server just doesn't already recognize there is already a VeeamBackup folder and start placing the replica files out there with the rest of my Veeam replicas.
Why would it need permissions? The folder alread exists from previous Veeam jobs running successfully from my other Veeam server at my other site. If it is permissions, what permissions are we talking about? The SSH permissions you setup from within Veeam? In the end, both Veeam servers should be putting the replica files (folders) on the same NAS, and in the already existing VeeamBackup folder.
Thanks Gostev.....permissions were in fact the issue. Went back to my primary Veeam server and compared settings and noticed the issue. Working now. Based on these speeds, would I be better off running my Veeam jobs from the secondary Veeam server (this one) and pull my replica files across the WAN rather than using my primary Veeam server and pushing them across my WAN link?
7 of 7 files processed
Total VM size: 70.00 GB
Processed size: 39.00 GB
Processing rate: 29 MB/s
Backup mode: SAN/NBD without changed block tracking
Start time: 4/8/2010 11:07:48 AM
Time remaining: 00:19:23
Until you upgrade to ESX4 and is able to leverage changed block tracking, your only option is to use primary Veeam Backup server in the production site. Remember that without changed block tracking, Veeam server has to read the whole VM image each time to determine the changes since last pass. Having Veeam server in source site ensures that VM scan traffic is local, and only changed blocks are sent over WAN to the target site.
After you upgrade to ESX4, you may reconsider this, because with ESX4 only changed blocks will be pulled from the source VM image.
