02-13-2015 04:23 AM
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
Solved! Go to Solution.
02-13-2015 04:40 AM
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.
02-13-2015 04:40 AM
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.
02-13-2015 05:29 AM
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 ?
02-13-2015 05:34 AM
Would this be the same issue in Netbackup ?
02-13-2015 06:24 AM
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.