04-27-2015 08:32 AM
Recently spent months working on an issue with support before engineering found out and mentioned it is a known issue that is not documented.
Using a 126.96.36.199 SRT would fail to restore a physical server using BMR. Had to upgrade my SRT and iso to use 188.8.131.52 after which the issue was resolved and I was able to restore the server as expected.
04-27-2015 10:18 AM
Thanks for sharing the update.
Is the issue related to any backup client O/S? (i.e. Unix/Linux/Windows?)
If Windows is affected, is the issue specific to 32-bit or 64-bit clients or both?
04-27-2015 04:38 PM
I was the support BL TSE who worked this case. The issue is not associate with any version of Windows clients that are being restored. It is more impacted by the NIC interfaces found on the client hardware and in the restore configuration. It does not always fail for a client recovery. If the target hardware only has a single NIC configured it should recover without error. If the target hardware has multiple NIC definition and all of hthem are seen and configured in the restore configuration, I think it will also work fine. This should not affect systems that are being restored back to the original hardware (self-restore, not a DSR restore).using the "current" configuration.
The error was introduced at 184.108.40.206 and repaired at 220.127.116.11.
04-28-2015 12:22 AM
Thank you Jaime.
04-28-2015 06:29 AM
Jaieme was the man.
As a note about the testing and re-production. Source system was a blade with 2 Nics, destination was also a blade with 2 nics, restore would fail. Restore to similar (same blade model) would fail, so the number of nics was not a part of this. The only thing not tested was restoring to exact same hardware as this is difficult with a production server that is working.
Booting the iso on physical systems takes an eternity, so shifted to restoring on a VM, where the issue is quickly reproduced. Test VM was configured to only have one nic, but as witnessed with the physical system used to test, having 2 nics (same as source) made no difference.
In the end we may lack the specific technical reasoning because the logs were usually empty, but the key is simply that the fix for this issue is to update the SRT.
04-28-2015 12:18 PM
The key was to update the SRT in what way? WIM file, or NetBackup Client? Or both? Or drivers too? Or something else? Thanks.
04-28-2015 06:57 PM
SRT NBU client code is updated using the Boot Server Assistant -> Shared Resource Tree Wizard.
Add a package to an existing SRT -> Add Release Update or Maintenance Pack to an SRT
From this panel select the SRT to update and the path to the NBU update "msi" file.
The rest is self explanatory.