The Direct NFS access mode cannot be used for VMs that have at least one snapshot. For this reason, the Direct NFS access mode has the following limitations: Veeam Backup & Replication cannot parse delta disks in the Direct NFS access mode. If NFS volumes are mounted on the ESX(i) host under names, not IP addresses, the volume names must be resolved by DNS from the backup proxy. The backup proxy must have ReadOnly/Write permissions and root access to the NFS datastore. 
The backup proxy used for VM data processing must have access to the NFS datastore(s) where VM disks are located. 2x NFS datastores (NFS01, NFS02) both connected to the ESXi host. #VEEAM BACKUP PROXY WINDOWS#
VBR-Proxy, Windows 2012 R2, 4vCPU, 4GB Memory.VBR-Server, Windows 2012 R2, 4vCPU, 6GB Memory.ESXi 5.5 U3 host, 80GB Memory, 4x 1Gbit Network interfaces.Synology DS1515+, 4x WD Red 3TB, 2x 1Gbit for Management (Bond ALB), 2x 1Gbit for iSCSI and NFS (Bond ALB).
The infrastructure I’m using for Direct NFS mode consists of the following: So if you plan to use NBD, design your solution with this “limitation” in mind. The NBD mode traffic always goes through the VMkernel which is selected as Management Interface. It leverages the VMware Network File Copy (NFC) protocol which is limited for a maximum throughput of 40% of the VMkernel interface (1Gbit => approx. Network Transport Mode is the slowest mode of the VDDK transport modes. If you can’t deploy backup proxies to every ESXi host you should use Network Transport Mode as transport mode instead.
value: 2 (if proxy on same host as VM is unavailable, Veeam Backup & Replication will use an available proxy on a different host, but force it to use network transport mode, so that no stun occurs this may be preferable when stun is not tolerable). value: 1 (if proxy on same host as VM is unavailable, Veeam Backup & Replication will fail over to a proxy on a different host and use available transport mode, which may cause stun). Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\. In addition you also need to create the following Registry key on the Veeam Backup and Replication Server: You can also mitigate this issue by deploying a Hot-Add proxy to every ESXi host where VMs reside that you want to backup by this method. For more information see VMware KB2010953. If your using NFSv4 datastores (vSphere 6.x or higher) you shouldn’t have this problem. This is unfortunately an issue with the NFSv3 protocol and the locking method. or the snapshot removal takes a long time to complete. VM become unresponsive for approximately 30 seconds. If the VM being backed up is on a different ESXi host then the Hot-Add proxy this could lead to either: During hot-add operations, the host on which the Hot-Add proxy resides will temporary take ownership of the VM by changing the contents of the LCK file. NFS datastores relies on a LCK file (e.g. The reason for this is that a NFS datastore doesn’t have a native capability like VMFS to determine which ESXi host is the owner of a particular VM. Virtual Appliance Mode was my preferred mode when doing backups in my home lab but I also saw that some of the VMs, most of the time vCenter and Domain Controller get stunned during the backup operations. Virtual Appliance Mode aka Hot-Add Mode. If you used Veeam Backup and Replication prior to v9 then the following transport modes are only available for backing up VMs on NFS datastores: Direct NFS is written from scratch by Veeam and doesn’t leverage the VDDK for backup and restore. 
In the case of Direct NFS you allow access to the NFS datastore from every Veeam Backup Proxy which uses the Direct NFS mode. Veeam introduced in Backup and Replication version 9 a new transport mode called Direct NFS. It’s similar to Direct SAN transport mode where you present the FC or iSCSI LUNs to the Backup Proxy Server.
0 kommentar(er)
