VM Restore NOT using SAN mode? and some other questions.

[ctchang]

I've successfully restore a 17GB w2k3 VM for testing by using v5, it's amazingly fast as well 5 mins only.

I've already configured using SAN mode for backup, it works fine, but how come restore doesn't ultilize SAN mode?

Instead it use COS/Service Console NIC instead.

Is it because if Windows Host (aka Veeam Backup) also WRITE data to VMFS, it will corrupt it?

Thanks,

[ctchang]

Other Questions:

1. After restore, under Event, it said the warning "Server Crashed at ..." at the time of being backup, so the backup is actually Crush Consistent (aka Pulling the power plug on the server), will this create some kind of problem on transaction application like AD, Exchange or SQL server? Do we have to specify VSS Administrator logon in backup option in order to protect this kind of potential problem? What's the best practice?

2. In the above w2k3 server, it has two VMDK, 1st one is C:\, 2nd one is D:\ (for backup c:\ stuff), I only SELECTED to backup the 1st VMDK, and there is an option saying Veeam will modify the VMX file to Exclude the rest UNSELECT VMDK and it will prevent problem in future restore as VM won't find the VMDK disk that's not being selected for backup, Shall I select/check that option as well?

Thanks,
Jack

[joergr]

Hi Jack,

nothing other than esx/i can and should *write* data to a multiple exposed vmfs lun, thus it is much safer that way you see

And ofcourse your machine thinks it was shutdown dirty when recovering from restore. How should it behave else? It was backuped during a live run. But with vss aware trigger inside windows made sure that the databases were in consistent state. So this is perfectly normal behaviour.

Your second question I don´t know the answer to, maybe Anton or Vitaliy can jump in

best regards,
Joerg

[Gostev]

0. It is because current version of vStorage API has some serious performance issues with direct restores to SAN. We actually have this option implemented, but disabled in the code until better days when VMware fixes the issue.

1. Yes, you have to enable application-aware image processing in Veeam Backup job settings to make sure all application and OS are captured in consistent state. Please review the corresponding section in the sticky FAQ topic.

2. Well, it is really up to you... this is why it is an option if there was single "correct" setting for this checkbox, then we simply would not give users this choice . But we cannot know the reason why you are excluding the disks from backup. For example, if this is RDM disk in physical mode, then you may not want to exclude it from VM config, so that restored VM continues using it. Or may disk D: is some universal disk that you will just copy over to VM manually as a part of restore, then again you may not want to exclude it from VM config.

[ctchang]

Thank you very much Joerg and Anton!

[raphael@schitz.net]

0. It is because current version of vStorage API has some serious performance issues with direct restores to SAN. We actually have this option implemented, but disabled in the code until better days when VMware fixes the issue.

Gostev, is this issue solved yet ?
Thanks

[ctchang]

Almost forgot my post, yeah, I would also like to know if v5.0.2 supports SAN Restore?

[foggy]

No, this option is still disabled in 5.0.2.

[raphael@schitz.net]

No, this option is still disabled in 5.0.2.

would it be possible to enable it for testing purpose ?

[ctchang]

No, this option is still disabled in 5.0.2.

Possible in Veeam 6 under ESX4.1? or we must use ESX5.0?

[Gostev]

Veeam Backup v6 provides a better method for full VM restores. This method is not affected by the above-mentioned vStorage API performance issue around thin disk restores via direct SAN connection. Thanks.

[wsdh]

Hi all,

I noticed that when restoring a VM with Veeam - we're using Veeam Backup & Replication 6.1 - Veeam is using NBD. I was wondering why Veeam is not using FC to restore directly to SAN. I found the following post on this forum:

http://forums.veeam.com/viewtopic.php?f ... 946#p40125

In the storage section of this post the following is mentioned:

Q: Does the product support restore directly to FC and iSCSI SAN?
A: Yes, via virtual disk hot add (data goes to the storage through the host's storage I/O stack).

Q: Any plans to support direct storage access for restores to FC and iSCSI SAN?
A: There are severe performance issues using vStorage API for Data Protection to restore thin virtual disks, making such restore approach unreasonable. Hot add restores do not suffer from this issue.

Could someone explain to me the difference between virtual disk hot add and direct storage access and if I will be able to restore VM's directly to SAN?

The reason I'm asking is of course performance: 1 Gbit Ethernet vs. 8 Gbit Fiber Channel.

[Vitaliy S.]

Please take a look at our sticky F.A.Q. topic which describes the differences between these modes in great details: VMware : [FAQ] FREQUENTLY ASKED QUESTIONS

If you want to increase the VM restore performance, then you need to use a virtual proxy server that should be located on the host with the direct connection to the target storage. Hope this helps!

[wsdh]

Our datacenter is fully backed-up using Veeam Backup & Replication. Daily incrementals are performed during the week with a synthetic full on friday. The .vbk and .vib (if any) files are stored on tape afterwards.

When we want to restore our datacenter on our failover location we restore the most recent .vbk and .vib files from tape to the local storage of a physical backup server and import them into Veeam. From there we can restore the VMs to our ESXi servers.

Do I understand correctly that

• - Introducing a virtual backup proxy on the ESXi host with direct connection to our SAN storage will not do us any good in this situation
  - I have to restore the Veeam files directly to our SAN in order to make use of a virtual backup proxy

Kind regards,

David

[foggy]

- Introducing a virtual backup proxy on the ESXi host with direct connection to our SAN storage will not do us any good in this situation

It will, actually. As Vitaliy already stated, introducing a virtual backup proxy on the ESXi host with direct connection to your target storage will allow to perform hotadd restore.

- I have to restore the Veeam files directly to our SAN in order to make use of a virtual backup proxy

This is not required, you can import backup files from any location.

[bartvincke]

Hello,

I have been looking around but I have not yet found an answer to the following:

does v6.5 support restoring through san-based backup instead of leaving over the network ?
I ask because my san based connection used for backups is 10GB while network fabric is only 1GB

I know that v5 could not do this but I have not come across an answer if this was changed in v6 or above.

thanks in advance

[jeffturl]

I am after a bit of advice, i have 4 Veeam proxies (Physical), 2 repositories (Physical) and 1 management server (virtual) (all running 2008R2). The 4 proxies have zoned to them all the luns presented to the ESXi servers, the 20 disks are all appear under disk management on the proxy servers, all show as online.

For some reason all my restores use NBD as opposed to direct SAN, i have tried setting the proxies to use direct san and fallback to network, but they always seem to use NBD for restores. am i missing something obvious? the only place to set this as far as i can tell is under 'backup infrastructure' and 'backup proxies'

The repository servers each have some large capacity luns presented to them and only them.

I assume on the proxy servers the ESXi disks should show as online and healthy but not directly accessible via a windows server?

Thanks
Jeff

[tsightler]

Restores cannot use direct SAN. If you'd like you can configure a single virtual proxy and use it to perform restores via hotadd. You could potentially even use your management server since it is already virtual.

[gmorris]

Just started a test DR restore [at DR site] using the latest version of Veeam v7.0.0.715 [VMWare 5.1] and noticed that during the restores the jobs are using [nbt] instead of [san] mode. When I run a backup job [on the VM I just restored] the job uses [san] which it should. Does anyone have any experiance with this? Is this normal behaviour?

thanks,

Glen

[foggy]

Glen, Direct SAN mode cannot be used for restores due to the reasons outlined above in this topic. For faster restores, consider using hotadd mode instead. Thanks.

[maverick964_uk]

Using Veeam 6.5 I am testing the use of physical proxy servers (HP DL380 G8).
Backup via direct SAN mode is good so thats great....

However.....when I select a physical proxy for restore it doesnt use "direct SAN" it uses NBD.

The messages state "No available proxies are connected to the ESXi management network". Is there another network I need to get the proxies connected to ??

thanks

[veremin]

Hi, Mike,

As mentioned, Direct SAN mode can't be used for restoration tasks. More information can be found in the posts provided above.

Thanks.

[maverick964_uk]

I assume the feature will get switched on once VMware resolve the issue??

[foggy]

Look at the OP date - they didn't manage to do this for years...

[idc2014]

hello everybody ;


why when i restore vm it is using source proxy vmware [nbd] ??


and how i can restore using [san]

[veremin]

Direct SAN mode can't be used for restore operations. In order to speed up process it's recommended to have a virtual proxy specified in Hot Add mode. Thanks.

[mcvosi]

I ran through some trial restores and noticed that when restoring they don't use Direct SAN access. Is that normal? My backups work just fine.

[foggy]

Matthew, currently direct SAN restores are not available. Please wait for v8 availability.

[mcvosi]

Got it. I guess it would help to search!

Thx

[veremin]

Just for your information - since version 8 has been released, it's now possible to utilize Direct SAN mode for restore. There are several requirements that should be met, though (such as, this mode works with thick disks only, etc.). Thanks.