Consider the following:
- 6 remote offices in several cities, all with vsphere 6 with NFS datastores, NFS in seperate subnet (NFS IP is NOT reachable from veeam backup proxy in head office)
- 1 big production storage and 1 backup storagein head office also vsphere 6 with NFS datastores in seperate subnet (all NFS IPs rachable from veeam backup proxy in head office)
- All datastores (about 30 TB) all snapvaulted to a central backupstorage (netapp) to the head office (daily veeam job with netapp snapvaut controlled by veeam) --> works really perfect and extremly quick!!!
- We now should backup the snapvault destinations to a third storage (this time a veeam repository) und from there to tape for archival and additional disaster recovery protection
We designed this by deploying a physical, dual CPU veeam proxy with 10G connection to backup-storage (where all snapvaulted datastores are) and creating a veeam job to repository and creating a secondary target "Netapp SnapVault" with the checkbox "use as the datasource" enabled.
For all NFS datastores in our head office that works really fine--> backup is copied from the snapvault destination. But all jobs from remoteoffices fail with error: "Unable to allocate processing resources. Error: No backup proxy is able to process this VM due to proxy processing mode restrictions. "
--> Difference between head and remoteoffice is that the NFS IP from the primary NFS datatsore is reachable for veeam proxy, NFS IP from primary datastores from remote offices not. But veeam doesn't have to copy files from the remote office datastore, because we have set the checkbox "use as the datasource" in the snapvault destination, and the snapvault destination IS reachable from veeam backup proxy.
- Is my assumption correct that backup with direct storage access fails because the NFS IP from primary storage/datastores are not reachable from proxy in head office?
- And when yes, why has the NFS IP of primary storage to be reachable for direct storage access when backing up from the snapvault destination? The snapvault job without veeam backup to repository is also controlled by veeam and works perfect even without reachable primary storage NFS IP. Do i really have to route the complete NFS Subnet over our WAN to be able to backup from snapvaiult destination on the head office?
- Or do you have any other suggestions how to solve this issue?