direct storage Backup from Netapp SnapVault as a datasource

[plandata_at]

Hi!

Case #01822225
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.

My questions:
- 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?
Thanks!!

[foggy]

- 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?

Yes. Currently this unneeded (in your case) check is performed during rescan procedure.

- 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?

Yes, this is the workaround to this issue that we're planning to address in one of the future versions. Thanks for the heads up!

[plandata_at]

Thanks foggy for your answer,

indeed, this is not a very good design, because normally we would never route NFS storage networks over WAN......!?!

Do you have any timeline when this will be resolved?

[plandata_at]

an additional question:
would it be possible to address this issue by deploying a veeam proxy with access to the NFS IP of the primary storage on remote office side while veem keeps using the proxy in the head office for backup traffic?

Would be nice if thi issue will be solved soon, because we were recommending veeam in connection with netapp snapmirror for really big data, but this issue is really a big downside and keeps us struggling.....

[larry]

My NFS mounts and NetApp snapmirror traffic I setup on a new vlan at both sites. On my Veeam proxy I set a second nic on that vlan. ESX servers I made a storage VLAN to these new networks. All works. The NetApp boxes already needed to talk across the WAN. None of the remote ESX server know about the NFS at the other site and no traffic moves between them. I did not expose my NFS to and other networks, just these new ones. My Veeam server also has a physical nic to that network which you will want so you can remotely browse the SAN snap shots, do a FLR from the remote SAN snapshot. This also allow Veeams to control the snapshots and snap mirrors. Having Veeam controlling the snapshots they are all application consistent. I can also do many local snapshots during production hours but snap mirror only after hours and then again right before production starts again. High priority data stores I do a snap mirror ever hour as the RPO is 1 hour. I hope I helped with your question, was not sure when reading.

My only WAN traffic is NetApp. My ESX and Veeam does not pull data over the WAN. If a backup from snapmirror fails I do not allow fail over to WAN.

[foggy]

would it be possible to address this issue by deploying a veeam proxy with access to the NFS IP of the primary storage on remote office side while veem keeps using the proxy in the head office for backup traffic?

Should be possible.

Would be nice if thi issue will be solved soon, because we were recommending veeam in connection with netapp snapmirror for really big data, but this issue is really a big downside and keeps us struggling.....

This is planned to be addressed in Veeam B&R 9.5.

[plandata_at]

This is planned to be addressed in Veeam B&R 9.5.

Wonderfull, thx!!

[plandata_at]

This is planned to be addressed in Veeam B&R 9.5.

Just a short question before changing our environment for testing. Is this working in 9.5 now?

[foggy]

Yes, in Veeam B&R v9.5, target proxy doesn't require access to the primary datastore.