BackupExec 14 Restore VM uses wrong NIC from ESX Host

[venetis]

Basic Scenario

============

Windows 2008 Physical Server running BackupExec 2014 SP1

ESX 5.0 Host managed by Virtual Centre (on VM)

The Backup server is running on a backup LAN with complete separation from Data traffic, but can communicate with VC  /and the ESX Host over this LAN and all names seem to resolve.

Backup LAN 10.x.x.x

Data LAN 15.x.x.x

Things that work

All over Backup LAN 10.x.x.x addresses

Ping Backup server <-> Virtual Centre

Ping Backup server <-> ESX Server

Ping ESX host <-> backup server

Ping Virtual Centre <-> Backup Server

Backup of local devices on Backup server

Backup of physical Host via Client

Backup of FULL VM and granular index over SAN Transport

Backup of VM via Client if extra NIC on Backup LAN is configured

Restore of files via Client if extra NIC on Backup LAN is configured

Issue

When trying to restore FULL VM Image the wizard runs fine and allows me to brose all the required resource folders (Hosts / storage / network / Resource pools and folders)

The job starts and contacts the VC and creates the VM shell as instructed on the correct host, confirms this - and then tries to establish a connection to transfer the data and according to the log files it decides to do this over the INCORRECT network.

I have tried all sorts on name resolution checks as historically this has been issues on other locations but with no reward, so any suggestions on either troubleshooting or resolution – or is this never going to work with a separate Backup LAN ???

Thanks

Rob

[Colin_Weaver · Accepted solution]

OK in your list of things that work you do not state the effect of an NBD Transport backup of the VM - I suspect that also does not use your Backup LAN - probably because we get addressing details from the vCenter for where the NDB connection should be on the ESX host and then make use of that connection.

Note I am guessing about this slightly as I am not aware that Symantec has done any official testing or design work to use Backup/Secondary network with the NBD Transport mechanism for VMware

You also might not be aware that you cannot do SAN transport restores in the current version of BE as such this does limit your restore capability (currently) This limitation came about when the VDDK (supplied by VMware) had issues that could not be fixed in a predictable timescale. These issues are in theory now fixed and Symantec have been working to re-implement SAN Transport restore support (after suitable testing and development). At this current time (pending identification of any major issues during testing) this will be re-introduced on BE 15 and allow your restore to avoid using the LAN.

[venetis]

Colin,

Thanks for the prompt response, and useful comment.

I am using SAN transport for the backups as its simple and more efficient, and i have previously utilised to great effect... and its working fine !

And this problem only came to light when i discovered the issue with SAN **restore** not being available as you state - so take a step back to NBD restore which is when i discover this limitation with the exisitng environment and it seems for the data transfer to only utilise the primary management network connection and ignore the previous connection that has worked to pass the VMX config data .... frustrating.

This is curently testing in a sandpit and seems to highlight a limitation of the existing setup here along with the SAN restore issue in the VMWare API - I will therefore have to try and get a modification to the environment to allow an ESX host to Backup Server connection on the Main Data LAN.

Thanks again for you help with at least confirming this even though there is no solution there is no point wasting more time trying to work around it...!!!

Rob

Do you have any idea on GA availability for 2015 version ?

[venetis]

Would this be the same issue in Netbackup ?

[Colin_Weaver]

Well NetBackup would also have been affacted by the SAN transport limitaions as that was a vddk issue.

However they may have already released updated support for SAN transport as the fix has been available from VMware for a few months now, and they may have tested and support secondary/backup networks with VMware - unfortunately as NetBackup is a separate product with almost no technology crossover I can't really answer the question, you could try asking in the NetBackup forums.

WIth regards BE 15 - it is in beta testing now, so release date won't be far behind, however we cannot commit to a timescale at this current time.