Veritas NetBackup™ Bare Metal Restore™ Administrator's Guide
- Introducing Bare Metal Restore
- Configuring BMR
- Protecting clients
- Setting up restore environments
- Shared resource trees
- Pre-requisites for Shared Resource Tree
- Creating a shared resource tree
- Managing shared resource trees
- Adding software to a shared resource tree
- Importing a shared resource tree
- Copying a shared resource tree
- Deleting a shared resource tree
- Managing boot media
- Restoring clients
- BMR disk recovery behavior
- About restoring BMR clients using network boot
- About restoring BMR clients using media boot
- About restoring to a specific point in time
- About restoring to dissimilar disks
- Restoring to a dissimilar system
- About restoring NetBackup media servers
- About external procedures
- About external procedure environment variables
- About SAN (storage area network) support
- About multiple network interface support
- Managing Windows drivers packages
- Managing clients and configurations
- Client configuration properties
- Managing BMR boot servers
- Troubleshooting
- Troubleshooting issues regarding creation of virtual machine from client backup
- A restore task may remain in a finalized state in the disaster recovery domain even after the client restores successfully
- Creating virtual machine from client backup
- Virtual machine creation from backup
- Monitoring Bare Metal Restore Activity
- Appendix A. NetBackup BMR related appendices
- Network services configurations on BMR boot Server
- BMR client recovery to other NetBackup Domain using Auto Image Replication
Client network based boot issue
Different operating systems use different network protocols for network boot. BMR leverages this protocol/s for starting network-based client recovery. For example, Windows, Linux and Solaris-x86 uses PXE based network boot which comprises DHCP, TFTP protocols.
In case of,
Windows: BMR has PXE and TFTP services running on the BMR boot server. DHCP can be any server in the same subnet.
Linux: DHCP, TFTP services needs to be running on the boot server providing client network boot. (Note: Once services are deployed and running on boot server; BMR automatically register/de-register them to enable client network boot.) Sometimes it happens that in the same subnet where client recovery is being done has multiple network boot protocol servers running. One of them is correct PXE/DHCP/bootp servers which can assign IP_address to BMR client upon network boot. In such environment when client boots over network for BMR recovery, its network boot request gets broadcasted and it can be reached to unintended network boot server (PXE/DHCP/BOOTP) first. In such case it can return failure and BMR recovery may fail.
So ensure that no other network boot services except the valid one providing BMR client network boot is running in the same subnet. Note that this is limitation with PXE, DHCP, BOOTP boot protocols themselves where first DHCP reply failure stops network boot process.