Backup and restore operations
Policies can be configured to use the NetBackup media server as a backup host. This allows the performance and throughput of VMware backup operations to scale naturally.
Storage unit groups
You can combine the flexibility of backup media servers with a standard feature of NetBackup: storage unit groups. Create a storage unit group that contains the storage units that your media servers can access. Assigning this storage unit as storage for the policy and selecting the Backup Media Server as the backup host will allow any of the media servers to operate as a backup host.
Use storage unit groups with care when you use deduplication storage units, as it might result in a reduction in overall duplication rates. Refer to the NetBackup Deduplication Guide for best practices around storage unit groups.
Complete LAN-free backups
Using the correct VMware storage layout and NetBackup storage configuration with a combined Backup Host and Media Server can achieve a complete LAN-free backup.
Greater Host redundancy
If one media server goes down, another media server takes over.
Faster backup
The media server can read the data from the datastore and send the data straight to the storage device. Without media server access to storage devices, an ordinary backup host must send the backup data over the local network to the media server.
NetBackup support various transport modes supported by underlying vSphere Storage APIs. Each transport mode works the best in specific scenarios. Choosing the right transport mode for an environment is critical for smooth backup or restore operations. Following are some performance, tuning, and compatibility notes of various transport modes and how components of NetBackup interacts with them. For more detailed notes and configuration steps, refer to the NetBackup for VMware Administrator's Guide
SAN transport
The SAN transport mode requires the VMware Backup Host to reside on a physical machine with access to Fibre Channel or iSCSI SAN containing the virtual disks to be accessed. This is an efficient data path because no data needs to be transferred through the production ESX/ESXi host.
When using SAN, make sure that datastore LUNs are accessible to the VMware backup host.
SAN transport is usually the best choice for backups when running on a physical VMware backup host. However, it is disabled inside virtual machines, so use HotAdd instead on a virtual VMware backup host.
SAN transport is not always the best choice for restores. It offers the best performance on thick disks, but the worst performance on thin disks, because of the way vStorage APIs work. For thin disk restore, LAN (NBD) is faster.
The job may be slow when you restore to a vCenter Server. For greater speed, designate a VMware Restore ESX server as the destination for the restore.
Too many paths. VDDK does not cache device paths. If there are too many paths zoned to a single host, it needs to determine which path to use for each disk, which can slow down the performance. On NetBackup appliances, VxDMP alleviates this problem to some extent, and also load-balances across multiple paths on appliances. However, it is recommended to avoid too many zoned paths.
NBD transport
In this mode, the ESX/ESXi host reads data from storage and sends it across a network to the VMware backup host. As its name implies, this transport mode is not LAN‐free, unlike SAN transport.
The VMware backup server can be a virtual machine, so you can use a resource pool and scheduling capabilities of VMware vSphere to minimize the performance impact of backup. For example, you can put the VMware backup host in a different resource pool than the production ESX/ESXi hosts, with lower priority for backup.
Because the data in this case is read by the ESX/ESXi server from storage and then sent to VMware backup host, there must be network connectivity between ESX/ESXi server and VMware backup host. If the VMware backup host has connectivity to the vCenter server but not the ESX/ESXi server, snapshots will succeed but vmdk read/write operations will fail.
The VMware backup host needs the ability to connect to TCP port 902 on ESX/ESXi hosts while using NBD/NBDSSL for backups and restores.
VMware uses network file copy (NFC) protocol to read VMDK using NBD transport mode. You need one NFC connection for each VMDK file being backed up. In the older version of vCenter/ESX, there is a limit on the number of NFC connections that can be made per ESX/vCenter server. Backup and restore operations using NBD might hang if this limit is reached. In recent versions of vCenter/ESX, VMware has added additional limits in terms of the total size of NFC connection buffers, which for vSphere 6.x/7.x are 32 or 48 MBs per ESX host.
Dedicated NICs for NBD. As of vSphere 7.0, ESXi hosts support a dedicated network for NBD transport. This mechanism can be enabled by applying the vSphereBackupNFC tag to a NIC using VMware CLI esxcli. NetBackup 8.3 and later versions support this.
HotAdd transport
When running VMware backup host on a Virtual Machine, vStorage APIs can take advantage of the SCSI HotAdd capability of the ESX/ESXi server to attach the VMDKs of a virtual machine being backed up to the VMware backup host. This is referred to as HotAdd transport mode.
HotAdd works only with virtual machines with SCSI disks and is not supported for backing up virtual machines with IDE disks. The paravirtual SCSI controller (PVSCSI) is the recommended default for HotAdd, but other controller types work too.
A single SCSI controller can have a maximum of 15 disks attached. To run multiple concurrent jobs totally more than 15 disks it is necessary to add more SCSI controllers to the HotAdd host. A maximum number of 4 SCSI controllers can be added to a HotAdd host, so a total of 60 devices are supported at the maximum.
HotAdd requires that the VMware backup host have access to datastores where the virtual machine being backed up resides. This essentially means:
ESX where the VMware backup host is running should have access to datastores where the virtual machine being backed up resides.
Both the VMware backup host and virtual machine being backed up should be under the same datacenter.
HotAdd cannot be used if the VMFS block size of the datastore containing the virtual machine folder for the target virtual machine does not match the VMFS block size of the datastore containing the VMware backup host virtual machine. For example, if you back up a virtual disk on a datastore with 1MB blocks, the VMware backup host must also be on a datastore with 1MB blocks.
Transport mode notes:
NBD transport
If the attempt to restore a full virtual machine fails while using the SAN transport type, try the NBD transport type instead.
Slow performance of NBD
Restoring a virtual machine with a transport mode of NBD or NBDSSL may be slow in the following cases:
The virtual machine had many small data extents due to heavy fragmentation. (A file system extent is a contiguous storage area defined by block offset and size.)
The restore is from a block-level incremental backup and the changed blocks on the disk were heavily fragmented when the incremental backup occurred.
For faster restores in either of these cases, use the hotadd transport mode instead of NBD or NBDSSL.
For more details and troubleshooting, see the following Veritas Knowledge Base articles: