3 reasons why direct SAN restore failover to NBD


Userlevel 7
Badge +6
  • Veeam Legend, Veeam Vanguard
  • 771 comments

 

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.

 

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.

 

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.

13 comments

Userlevel 7
Badge +5

Thx @vNote42 for this great post. Normally when I use the Direct SAN method with a physical backup server, I normally create a virtual proxy server. This way the hot-add method can be used for restoring which is better than NBD. We normally have not always control over the creation of a new virtual machine (used disk : thick - thin provisioned) because of working with several engineers or even the customer itself.

Therefore I mostly recommended creating one virtual proxy server if using shared storage and direct san method is being used for backups.

This is a great tip for sure. Thanks for that.

Userlevel 7
Badge +3

Thx @vNote42 ! Great minds think a like !!! :-) :-) :-)

Userlevel 7
Badge +6

Thx @vNote42 for this great post. Normally when I use the Direct SAN method with a physical backup server, I normally create a virtual proxy server. This way the hot-add method can be used for restoring which is better than NBD. We normally have not always control over the creation of a new virtual machine (used disk : thick - thin provisioned) because of working with several engineers or even the customer itself.

Therefore I mostly recommended creating one virtual proxy server if using shared storage and direct san method is being used for backups.

Thanks! Fully agree, I also recommend to install virtual proxy even is direct SAN access is in place. Just for the case, something does not work as expected.

Userlevel 7
Badge +3

Thx @vNote42 for this great post. Normally when I use the Direct SAN method with a physical backup server, I normally create a virtual proxy server. This way the hot-add method can be used for restoring which is better than NBD. We normally have not always control over the creation of a new virtual machine (used disk : thick - thin provisioned) because of working with several engineers or even the customer itself.

Therefore I mostly recommended creating one virtual proxy server if using shared storage and direct san method is being used for backups.

Userlevel 7
Badge +4

Some great tips :thumbsup_tone2:@vNote42 , thank you.

Regarding the “Disk is logically locked in Veeam proxy” topic - wouldn’t it be enough to reboot the proxy?

As far as I know, not it isn’t enough.

So you could also use this logically read-only state for security reasons.


OK, thank you for the clarification. :sunglasses:

Userlevel 7
Badge +6

Some great tips :thumbsup_tone2:@vNote42 , thank you.

Regarding the “Disk is logically locked in Veeam proxy” topic - wouldn’t it be enough to reboot the proxy?

As far as I know, not it isn’t enough.

So you could also use this logically read-only state for security reasons.

Userlevel 7
Badge +5

Great article @vNote42!

Userlevel 7
Badge +3

Good article @vNote42 , i have already read some parts on the link below. Your write is more complete :)


https://helpcenter.veeam.com/docs/backup/vsphere/direct_san_access_writing.html?ver=110

Userlevel 7
Badge +4

Some great tips :thumbsup_tone2:@vNote42 , thank you.

Regarding the “Disk is logically locked in Veeam proxy” topic - wouldn’t it be enough to reboot the proxy?

Userlevel 7
Badge +3

Good one @vNote42 , thanks 

Userlevel 7
Badge +5

Great writeup Wolfgang.  Direct SAN is great for backups but it is interesting how restore can be tricky as noted.

Thanks Chris! You are right! It is really important to test direct SAN restore during implementation as well!

Agreed 100% on that one since it could fail many ways.

Userlevel 7
Badge +6

Great writeup Wolfgang.  Direct SAN is great for backups but it is interesting how restore can be tricky as noted.

Thanks Chris! You are right! It is really important to test direct SAN restore during implementation as well!

Userlevel 7
Badge +5

Great writeup Wolfgang.  Direct SAN is great for backups but it is interesting how restore can be tricky as noted.

Comment