Nuts and bolts in NetBackup for VMware: Transport methods and TCP ports
It had been a while since my last blog on NetBackup for VMware. The next in line in that series was restore process flow. However, since there had been many questions on transport methods and TCP ports, let us talk about those for now. I will get to restore process flow soon!
Thus this blog is just an addendum to Understanding V-Ray vision through backup process flow. As that blog was too long already, I didn’t spend much time explaining various transport types and TCP ports but I received so many questions on those. Sorry for the delay.
Let us examine the transport types and ports usage through the view from VMware backup host.
There are three unique ways a backup host can stream data from VM data store. They are SAN, hot-add and NBD transports.
SAN TRANSPORT
The VMware backup host must be a physical system in order to use SAN transport. The data store LUNs are zoned to the backup host. The backup host can directly read VMDK objects from the datastore using vADP. The data stores can be Fibre Channel or iSCSI connected.
Pros:
True offhost backups, zero resources tapped from ESX/ESXi hosts
Cons:
Works only for SAN attached (Fibre Channel or iSCSI) data stores
HOT-ADD TRANSPORT
You can think of hot-add transport as a special case of SAN transport where the backup host is also a virtual machine. Plus there is a bonus, it works for non-SAN data stores as well. The backup host VM accesses the VMDK objects of other VMs directly from the data store (similar to SAN transport). It can protect all VMs on datastores to which it has access.
Pros:
No need for a physical backup host
Does provide offhost backups for those VMs not collocated with VM backup host
The most efficient backup method for NFS based data stores (e.g. NetApp or FileStore providing VM storage)
Cons:
It does use ESX server resources where the VM backup host is deployed
You cannot protect VMDK files larger than 1TB (a vADP limitation with hot-add)
NBD TRANSPORT
NBD stands for network block device. In this method, VMware Network File Copy (NFC) protocol is used such that the VMDK object looks like a block device to the backup host which can be read through network. You need one NFC connection for each VMDK file being backed up. Thus backup is streamed from ESX/ESXi system’s VMkernel port to VMware backup host. If your ESX/ESXi hosts have VMKernel ports (known as the management ports) with dedicated uplinks, your virtual machine traffic links are not affected.
Pros:
Works for all kinds of data stores, even the ones directly attached (DAS) to ESX hosts
The simplest one to setup from infrastructure perspective works with both physical and virtual backup hosts.
Cons:
Not an offhost solution. ESX resources are used for backups.
Which one is right for you? Well, it depends on your business needs. For a large enterprise data center where you already have invested heavily on Fibre Channel SAN for your vSphere infrastructure, SAN transport is ideal. Hot-add can also be used especially if you like to spread backup hosts onto to multiple multi-node ESX clusters. With the increasing popularity of 10Gb Ethernet, NBD is not inferior either. Good news is that NetBackup has the ability to automatically try various transports during backups.
TCP PORTS TO VSPHERE INFRASTRUCTURE
What ports are needed from NetBackup to vSphere infrastructure? The answer is quite simple; you need access to TCP port 443 and 902.
Ability to connect to TCP port 443 on vCenter server is mandatory. This is the port at which NetBackup connects for all things needed from vCenter server. VM discovery requests, snapshot creation, snapshot deletion etc.
The backup host may also need the ability to connect to TCP port 902 on ESX/ESXi hosts. This is needed for specific use cases. If these are not applicable to your environment, no need for this port to be opened in firewall.
1. You are using NBD/NBDSSL transport for backups and/or restores.
2. You are doing restores through Restore ESX server bypassing vCenter