3 reasons why direct SAN restore failover to NBD with Veeam VBR

Backups of VMware vSphere VMs can be done with one of three transport modes. Each of these modes also provide the possibility to restore data. This post is about 3 reasons why direct SAN restore failover to NBD with Veeam Backup&Replication (VBR).

Incorrect VMDK type

Veeam can only perform direct SAN restore with thick provisioned VMDKs. If any disk of a VM is thin provisioned, restore will not leverage SAN directly. Both, thick eager and lazy zeroed are supported. In my experience, eager zeroed is much faster from a restore point of view! So I recommend, to use this format.

Note: you should not rely on the provisioning type you chose at VMDK creation: Thick provisioned disk can become thin if it is expanded.

Fortunately, Veeam provides the possibility to change disk type in restore wizard. So you can be sure to use thick VMDKs when you enter this within the wizard. See here in Full VM Restore wizard:

And in Virtual Disk Restore wizard:

Disk is logically locked in Veeam proxy

If your Veeam proxy server is Windows based, it could happen, mapped storage LUN is logically locked. This can be checked using diskpart.exe. After starting diskpart.exe, run list disk to show all mapped volumes. Select disk number you want to check possible lock by running select disk n, with n the disk number. Finally run attributes disk to show settings of selected disk. See sample output in screenshot.

As you can see first disk is not in Read-only state, second one is. To reset this state, run attributes disk clear readonly. It could be necessary to reboot the proxy after this command.

More on this topic you can read:

• Veeam BP – VMware vSphere Proxy
• Veeam restore via SAN is not working – fall back to NBD?

Certificate issue

This one is much more tricky! Recently I had to troubleshoot not working direct SAN restore. To keep it short, Veeam support has done an excellent job in finding the root cause: certificates handling. It was hard to find, because we configured storage snapshot integration. Therefore backup could leverage direct SAN access, and – more mean – some error messages does not appear in logs that would indicate the issue.

All in all, it is a know issue with an rather simple solution: If you are using a certificate in your vCenter, your Veeam proxies do not trust, you need to install it on your proxies. This could be a self-signed or even a internal CA certificate when your proxies are no members of the domain.

Solution steps:

1. Export current vCenter certificate chain as .zip-file.
   
2. Install *.0.crt, *.1.crt, and so on, certificates as Trusted Root Certification Authorities on each proxy that could be used for volume mapping.
   

Read How to download and install vCenter Server root certificates for more details.

Notes

• Direct SAN backup can work without any issue even if one or more of points above apply. Interesting here is the problem with the certificate. Backup can still get data directly from SAN, when Array is integrated in backup workflow.
• Suffering from poor backup performance with direct SAN access? Maybe my post Poor SAN transport mode performance helps.
• Get your trial of Veeam Backup&Replication!