Generally, when designing backup infrastructures, it is preferable to set up a direct connection between the data mover (“Backup Server” or “Proxy”, in Veeam terminology) and the production storage where your data resides. This is commonly referred to as “LAN-Free” configuration, because the backup traffic does not impact on your LAN. Actually, what I described is only half of the job: a direct access to the production storage ensures LAN-Free read operations – to obtain a real 100% LAN-Free backup, also the target storage (“Repository” in Veeam terms) must be directly connected.

As you might already know, Veeam Backup & Replication supports both VMware vSphere and Microsoft Hyper-V environments. The backup and recovery mechanics are quite different between the two hypervisors, as well as the steps needed to configure a LAN-Free backup. So I wrote a separate blog post about configuring LAN-Free backup for Hyper-V environments.

It should be noted that by default, when you install Veeam Backup & Replication, the backup server is automatically configured as a backup proxy and repository. So it is perfectly possible to have a single machine holding all roles – this is of course suggested only in small environments.

The good thing about this approach is that you can grow and scale as you like, plus you can easily adapt the backup/replication infrastructure to your needs, for example if you have a distributed infrastructure among different sites.

LAN-Free backups in VMware vSphere

Configuring LAN-Free data reading

In vSphere environments, Veeam Backup & Replication leverages the VADP framework to read VM data. VADP offers the “Direct SAN” transport mode among others. To enable LAN-Free reading of VM data, the Veeam Backup & Replication Proxy component must have visibility of the vSphere shared datastores on which it resides (either FC or iSCSI – NFS and local storage are not supported).

The steps to configure your B&R Proxy to access the shared storage vary depending on your infrastructure (storage vendor and model, protocol, switches…) and is out of this post’s scope.

Play it safe!

Giving a Windows system access to your VMFS datastore can potentially lead to trouble – if Windows mounts and initializes (re-signatures) the volume, it becomes corrupted and unreadable from the vSphere hosts. If it happens, don’t panic! It can usually be fixed quite easily from VMware support, or you can even fix it yourself (not recommended).

If your SAN and/or switch infrastructure allows it, you should give the Windows server read-only access to the VMFS volumes. But it’s not always possible. A common approach is disabling the automatic mounting of new volumes in Windows.

In Windows 2003, it was required to disable the Automount feature and there was no distinction between shared volumes and local, non-shared volumes (such as removable or directly-attached ones).

Starting from Windows 2008 and upwards, only the SAN Policy setting, accessible via diskpart, is needed. The policy can either be “Online All”, “Offline All” or “Offline Shared”. Even if AutoMount is enabled, new volumes/LUNs will not be automatically online if SAN Policy is set to “Offline Shared”.

You can check your current SAN policy settings using the san command within diskpart. Note that this does not completely remove the risk of someone manually onlining the volume, so you should be careful about who has administrative access to that Windows system.

• In Windows Server 2012 (any edition) the default value for SAN Policy is “Offline Shared”