Note: When making use of the NBD Transport mode, virtual disks cannot be larger than 1TB each. More information here.


SAN Transport mode requires Altaro VM Backup to run on a machine with access to SAN storage (Fibre Channel, iSCSI, or SAS connected) containing the virtual disks to be accessed. This is an efficient method because no data needs to be transferred through the production VMware ESX/ESXi host.


Altaro VM Backup will, by default, attempt to use Direct SAN Transport mode when available and will failover to other Virtual Disk Transport Methods if SAN Transport is not available.


Below are a few requirements to be taken into consideration when attempting to use SAN Transport Mode:

  1. The datastore must be of VMFS type

  2. Altaro VM Backup mustn't be installed on a Virtual Machine and must be on a physical machine.

  3. The LUN/Volume for each datastore containing a VM's data files, must be exposed to the machine running Altaro VM Backup

  4. The LUN/Volume must appear in Disk Management on the Altaro VM Backup machine

  5. Use DISKPART to verify automount disabled and automount scrub prior to mapping the LUNs. In some cases if this is not enough, you may need to set it to san policy=onlineall. It's imperative that you do not allow Windows to initialize any VMFS volumes that you will be exposing to it.


Further reading: https://kb.vmware.com/kb/2002227



Troubleshooting Tips


  1. To verify which transport mode is being used by Altaro VM Backup you can search for the following entry in the log file of the backup job in question:
    Altaro.Providers.Vmware.BackupRestore.VmwareRestoreStream.Connect(): Opening Disk
    Altaro.Providers.Vmware.BackupRestore.VmwareRestoreStream.Connect(): Disk Opened
    Altaro.Providers.Vmware.BackupRestore.VmwareRestoreStream..ctor(): Connected with transport mode: san
    Note: The backup job logs can be found in C:\ProgramData\Altaro\AltaroBackupProfile\Logs\OpControllers\

  2. If you come across SSL subject name mismatch errors in the VMware VDDK logs, you can resolve this by importing the SSL certificate used by vCenter. Simply place it in the trusted CA container using the MMC certificates console for the computer account

  3. If Microsoft Windows is used as the VMware API Proxy instead of Linux, the following two Registry Keys must be created as the job will failover to NBD if they are not present:
    [HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Virtual Disk Development Kit]
    VerifySSLCertificates=dword:00000000 
    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.\VMware Virtual Disk Development Kit]
    VerifySSLCertificates=dword:00000000