cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to restore (Bare Metal Restore)

mndbnbp
Level 3

Hi.

Please tell me about Bare Metal Restore in Netbackup.

I created a boot media for restore with Bare Metal Restore.
I tried to restore using it, but I got an error.


Error message
"The restore has stopped due to the following error:Unable to configure network".


The configuration is as follows

Master Server: Windows Server 2019 Standard
Client: Windows Server 2019 Standard
Netbackup(master server/client): 9.1.0.1
Backup target: C:,System State:\,Shadow Copy Components:\

Network teaming is configured with LACP for both the client and master server.
We have two ports belonging to one teaming, each with a separate segment.
When restoring, we are using a single port with a backup segment.

Please let me know how to resolve this issue.

Also, if the client OS is Windows, is the above correct for the backup target?

Thanks.

 

 

スクリーンショット (186).png

1 ACCEPTED SOLUTION

Accepted Solutions

Nicolai
Moderator
Moderator
Partner    VIP   

Thanks for clarification.

Just to make it 100% sure we are on the same page, same subnet men's same IP range and subnet mask. When working with multihomed host, static routes and default gateways matter a lot.

There are logging utilities with-in Netbackup to help debugging BMR errors , pls see : https://www.veritas.com/content/support/en_US/doc/26437400-127352289-0/id-SF880424735-127352289

You use the vxlogview command to view the logs.

My recommendation would to be using vxlogview -p 51216 -X "jobid=restore job ID", then you should get all information from the restore job without digging into each OID debug log.

 

 

View solution in original post

3 REPLIES 3

Nicolai
Moderator
Moderator
Partner    VIP   

BMR is not easy to work with.

If restoring to a "backup network" you must ensure the master server can reach the backup network by:

  • Having client and master server on same subnetwork.
  • If not on same subnet, have static routes or default gateway pointing in the right direction.
  • Ensure host names for the different subnets are resolvable during restore.

You don't want BMR process to be confused about what networks that are reachable or not.

This somehow sound wrong to me. LACP is link aggregation, if connected to multiple segment, do you have 802.1Q running on top ?. And that may be a way to complex network configuration for BMR. Also remember if not using LACP, then the switch ports must be reconfigured back to access ports from port channels.

Network teaming is configured with LACP for both the client and master server.
We have two ports belonging to one teaming, each with a separate segment.

 

Hello @Nicolai 

Thank you for your answer.

I am sorry that my explanation is not clear.
The current network configuration of the server is as follows

・Master server settings
 Teaming A (subnet A): port 1, port 2
 Teaming B (subnet B): port 3, port 4
・Set up for the client
 Teaming A (subnet A): Port 1, Port 2
 Teaming C (subnet C): port 3, port 4

※"Teaming A (subnet A)" is the subnet used for backup.

As shown above, the master server and client are on the same subnet A.
Also, the default gateways are set to teaming B and C, respectively.

When restoring, one port on subnet A on the client side is connected to a port on the switch in the access VLAN.
We also unplug all cables except for that port.

 

Nicolai
Moderator
Moderator
Partner    VIP   

Thanks for clarification.

Just to make it 100% sure we are on the same page, same subnet men's same IP range and subnet mask. When working with multihomed host, static routes and default gateways matter a lot.

There are logging utilities with-in Netbackup to help debugging BMR errors , pls see : https://www.veritas.com/content/support/en_US/doc/26437400-127352289-0/id-SF880424735-127352289

You use the vxlogview command to view the logs.

My recommendation would to be using vxlogview -p 51216 -X "jobid=restore job ID", then you should get all information from the restore job without digging into each OID debug log.