Last week when I outlined a few considerations about whether to install Veeam Backup & Replication as a virtual or physical machine, a follow-up conversation reminded me of an important configuration scenario. If Veeam Backup & Replication is installed on a virtual machine with an iSCSI storage processor as the production storage for vSphere, you can configure the iSCSI initiator within the guest virtual machine. This enables Veeam Backup & Replication to access the production storage for vSphere directly.
Once you configure the iSCSI initiator, you will see your production VMFS LUNs appear in the disk management snap-in of the Veeam Backup & Replication server. Be sure to check out this is this post from Justin’s IT Blog about this topic. This is shown in the figure below:
This would require any zoning on the iSCSI target to include the iSCSI qualified name (IQN) of the Veeam Backup & Replication server to the storage provisioned for the vSphere (or VI3) environment. In this example, the storage is a 2 TB LUN that is formatted with VMFS. While the drive path is visible within Windows, do not try to initialize or format these LUNs within the disk management snap-in, as this could corrupt or overwrite data stored on the VMFS LUNs. Further, note that the Veeam Backup & Replication v5 and later setup automatically disables the automount feature of Windows. Automount allows for automatically mounting and assigning configuration to newly connected volumes. If you add a VMFS datastore to the Veeam Backup & Replication server, with automount enabled, the operating system may initialize and re-signature the volume. This would make it unrecognizable by the ESX(i) hosts.
Having these LUNs visible within disk management can ensure that all of the required LUNs are available to Veeam Backup & Replication, including viewing the target and LUN IDs as presented from the storage processor. Conversely, if all VMFS LUNs are not visible; there may be a zoning issue.
Direct SAN access processing mode allows Veeam Backup & Replication to communicate directly with the storage for the highest backup job performance. Further, if the backup target supports iSCSI or fibre channel; direct SAN access mode also enables a completely LAN-free backup implementation.
In the case of iSCSI storage, this usually means that the virtual machine that Veeam Backup & Replication is running on will have a presence of at least two (or more) networks (vNICs) as in most iSCSI storage networks are separated from other networks (including production networks), at least at a VLAN level. Should fibre channel storage be used as the backup target, NPIV can be leveraged to connect a virtual machine running Veeam Backup & Replication directly to the SAN fabric.
What configuration practices have you done with Veeam Backup & Replication as a virtual machine and iSCSI storage networks? Share your comments below.
