Hello,
I was evaluating a few backup methods an design variations for a Veeam Project. The result was a Backup from Storage Snapshot Concept with a dedicated Backup Transfer Network:
Concept details:
https://mycloudrevolution.com/en/2018/0 ... -snapshot/
Backup process works fine, the only problem is the restore. With the dedicated Backup network the restore is done in network mode.
Restore Problem:
Veeam tries to access the NetApp Storage system from Direct NFS Proxy via the NetApp SVM IP in NFS Network (Logs and Firewall Logs showed that) the additional IP in Backup network and Hot Add Proxy (both work for backup) are ignored and a fallback to network mode occures.
Is that by design or is it a bug?
Best regards,
Markus
-
- Expert
- Posts: 103
- Liked: 28 times
- Joined: Dec 08, 2014 2:30 pm
- Full Name: Markus Kraus
- Contact:
-
- Veeam Software
- Posts: 21138
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Direct NFS Restore
Hi Markus, hard to guess, it's better to open a case and provide logs for review. Thanks.
-
- VP, Product Management
- Posts: 6035
- Liked: 2860 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: Direct NFS Restore
Most likely be design. Direct NFS uses a different process from BfSS to determine what IP to use for connecting to the NFS share. With Direct NFS the IP/hostname information about the NFS datastore is gathered from the VMware environment to determine how Veeam should attempt to access the NFS server so it will try to connect using the same IP/hostname that the ESXi hosts use. My guess is, when we do a datastore scan, we can't figure out any way to reach these datastores via NFS using this information.
If you happen to be mounting your datastores via hostname, you could potentially use a host alias to get the Direct NFS proxy to resolve a different IP address from the ESXi hosts, but usually I see people mount NFS via IP address on their ESXi hosts. If you're in that latter group then the only real option is to provide some way for one of the proxies to access the NFS network.
You may be able to get creative and abuse a static route, manually adding a static route for the NFS IP but statically pointing it to the IP on the Backup network. I've not tested this with Netapp, but it works on most systems because you're effectively telling the Direct NFS proxy that to reach the NFS IP it should send the packet directly to the specified IP on the Netapp as if it is a gateway. Even though it's obviously not a gateway, and won't route per-se, because it already "owns" the other IP as well, most devices will simply respond on that interface anyway.
If you happen to be mounting your datastores via hostname, you could potentially use a host alias to get the Direct NFS proxy to resolve a different IP address from the ESXi hosts, but usually I see people mount NFS via IP address on their ESXi hosts. If you're in that latter group then the only real option is to provide some way for one of the proxies to access the NFS network.
You may be able to get creative and abuse a static route, manually adding a static route for the NFS IP but statically pointing it to the IP on the Backup network. I've not tested this with Netapp, but it works on most systems because you're effectively telling the Direct NFS proxy that to reach the NFS IP it should send the packet directly to the specified IP on the Netapp as if it is a gateway. Even though it's obviously not a gateway, and won't route per-se, because it already "owns" the other IP as well, most devices will simply respond on that interface anyway.
Who is online
Users browsing this forum: Bing [Bot], diego.garza, Google [Bot], Semrush [Bot] and 124 guests