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
BMR support for multi-pathing environment
BMR has compliance support for multi-pathing environments. What this means is, during the client's BMR backup which has BMR known multi-pathing environments set up; BMR automatically marks the multi-pathed disks restricted in that client's captured BMR configuration. This restricts the user to use those disks during recovery. Though any file systems running over the multi-pathed disks can be recovered to alternate non-multipathed disks. For example, if the client setup has EMC PowerPath enabled over SAN LUNs, then the BMR backup will mark those SAN LUNs as restricted. The user can recover file systems on top of them to either local disks or other SAN LUNs not having multi-path enabled.
BMR recovery environment has no multi-path software setup and configured (like EMC PP). Hence BMR recovery environment cannot identify multi-path enabled disks on given target hardware. Currently Supported Multi-pathing environments are:
EMC PowerPath on UNIX/Linux/Windows supported platforms
Linux Native Multi-pathing (support started with NetBackup BMR 7.5 release)
The details of the environment are as described in the following topics:
BMR supports only above mentioned multi-pathing environment setups. If the client being BMR backed-up has any one of these multi-pathing enabled; then while capturing client's BMR configuration, BMR resolves multi-paths to exact unique physical disk and shows it in BMR config. Also as mentioned above, BMR marks them restricted and avoids recovery time failure.
BMR backup will fail to identify unique disk names and BMR captured configuration will show multiple-disk names as shown by multi-path software. Also it will not be able to mark the disks restricted automatically. Here you need to copy BMR configuration using administrator GUI (Refer chapter Managing client configurations from NetBackup BMR Administrator's Guide)and identify MP disks and mark them restricted manually. If file systems on top of these MP disks need to be recovered then map them to other non-MP disks. If you ignore MP-based file systems recovery and restore only operating system then post BMR recovery if the multi-pathed disks are attached to the target host then file systems on top of them may come online automatically. Refer tables Actions for nonsystem disks and Import Actions for more details.
If the client setup has operating system volumes based on multi-pathing environment, then BMR cannot recover this system.