Veritas NetBackup™ Bare Metal Restore™ Administrator's Guide
- Introducing Bare Metal Restore
- Configuring BMR
- Protecting clients
- Setting up restore environments
- Shared resource trees
- About 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
- Enabling or disabling SRT exclusive use
- Repairing a damaged shared resource tree
- Breaking a stale shared resource tree lock
- Managing boot media
- Restoring clients
- BMR restore process
- Preparing a client for restore
- BMR disk recovery behavior
- About restoring BMR clients using network boot
- About restoring BMR clients using media boot
- Generic BMR Restore
- Generic Discovery of Hardware
- About restoring to a specific point in time
- About restoring to dissimilar disks
- Restoring to a dissimilar system
- About dissimilar system restore
- About discovering the configuration of the new system
- Creating an editable DSR configuration
- About adding NIC and MSD drivers
- About changing network interfaces
- About mapping disks in the restore configuration
- About creating boot media
- About restoring the client
- Logging on for the first time after system restore
- About restoring NetBackup media servers
- About restoring BMR boot servers
- About external procedures
- External procedure points and names
- About managing external procedures
- Specifying external procedures
- About external procedure data transfer
- About interaction with external procedures
- External procedure logging examples
- External procedure operational states
- About external procedure exit codes
- About external procedure error handling
- About external procedure environment variables
- About SAN (storage area network) support
- About multiple network interface support
- Port usage during restores
- Managing Windows drivers packages
- Managing clients and configurations
- About clients and configurations
- Copying a configuration
- Discovering a configuration
- Modifying a configuration
- Deleting a configuration
- Deleting a client
- Client configuration properties
- Managing BMR boot servers
- Troubleshooting
- Problems booting from CD or DVD
- Long restore times
- Solaris media boot network parameters issue
- How to recover client when BMR configuration is deleted accidentally
- First boot after BMR restore fails on UNIX platforms
- Client network based boot issue
- Verify backup failure while recovering Windows client
- The VM takes long time for booting after BMR Physical backup conversion to virtual machine is performed on 32-bit architecture Windows OS
- BMR-enabled physical backup to Virtual Machine conversion job fails on Windows platform
- Troubleshooting issues regarding creation of virtual machine from client backup
- Many services on Solaris 11 and newer print warning messages during a system boot and during BMR first boot
- Solaris Zone recovery on Solaris 11 and newer takes time to reconfigure after a BMR restore during first boot
- A Solaris BMR restore operation fails if the text-installer package is not present in the customized AI ISO
- The /boot partition must be on a separate partition for a multiple device-based OS configuration
- Multiple error messages might be displayed during the first boot after the restoration of a client with ZFS storage pools
- BMR may not format or clear the ZFS metadata
- Specifying the short name of the client to protect with Auto Image Replication and BMR
- A restore task may remain in a finalized state in the disaster recovery domain even after the client restores successfully
- Automatic boot may fail for HP-UX after a restore
- Prepare to Restore may not work for a Solaris client
- Use of Virtual Instance Converter (VIC) hosts on Windows (x64) having NetBackup 8.1 is not supported for NetBackup 8.0 and earlier clients
- PTR or PTD failure because of boot server version mismatch after upgrade
- Error messages for prepare to restore, prepare to discover, and the bmrprep command with reference to secure communication in BMR
- Creating virtual machine from client backup
- About creating virtual machine from backup
- BMR physical to virtual machine creation benefits and use cases
- Deployment diagram for virtual machine creation
- Client-VM conversion process flow
- Pre-requisites to create VM creation from backup
- Virtual machine creation from backup
- Virtual Machine Conversion Clients
- Converting client backup to VM
- Virtual Machine Options
- Virtual machine conversion storage destination
- Network connection selections
- Virtual machine conversion summary
- Direct Virtual Machine (VM) conversion (physical to virtual) tasks performed after the restore is complete
- Virtual Machine Conversion Tasks
- Restore Task Properties
- Creating custom configurations
- Virtual Machine Creation CLIs
- Monitoring Bare Metal Restore Activity
- Appendix A. NetBackup BMR related appendices
- Network services configurations on BMR boot Server
- About the support for Linux native multipath in BMR
- BMR support for multi-pathing environment
- BMR multipath matrix
- BMR support for virtual environment
- BMR Direct VM conversion support matrix
- About ZFS storage pool support
- Solaris zone recovery support
- BMR client recovery to other NetBackup Domain using Auto Image Replication
- Secure communication compatibility matrices for BMR for NetBackup 8.1.1 and later releases
Solaris zone recovery support
When using BMR to back up and restore Solaris Zones, you need to address some unique considerations.
Bare Metal Restore can restore a Solaris system running Zones. Although BMR cannot restore individual non-global zones, all non-global zones in a system are re-created as part of the global zone restoration. If global and non-global zones are based upon ZFS filesystems, then user does not require to do the 'vfstab' configuration."
To restore all non-global zones in a dissimilar disk restoration scenario
- Remap the file system that hosts the zone (also known as zone path) to restore the zone files.
If a non-global zone imports slices from the global zone that are not remapped, BMR removes the slices from the zone configuration.
If a non-global zone imports slices from the global zone that are remapped to different disks, BMR readjusts the zone configuration and any zone vfstab (ZONEPATH/root/etc/vfstab) entries to use the new device names.
If a non-global zone imports systems from the global zone file that are not remapped, BMR removes any references to them in the zone configuration.
- Test
You may have to re-create and restore all file systems imported or used by a non-global zone after BMR restoration. These file systems usually don't appear in the global zone vfstab (/etc/vfstab).
BMR relies on entries in /etc/vfstab to document the file systems that are subject to restoration. Dynamically-created and mounted file systems that do not appear in /etc/vfstab (even if backed up by NetBackup) do not automatically restore. The easiest way to force BMR to restore such file systems is to add an entry to /etc/vfstab that documents the devices and mount points used, with the field set to . Then, the dynamic file systems can continue to be used as before. BMR is aware of them, recreates them unless unmapped in DDR, and restores their contents if backed up by NetBackup.
Zone features cause dynamically mounted file systems to appear, as follows:
FS entries that involve devices in the global zone.
Device entries imported from the global zone but mounted either by the /etc/vfstab of the non-global zone, or dynamically by the zone itself.
To automate BMR zone restoration, Add entries to the global zone /etc/vfstab that cause BMR to restore them (unless unmapped by DDR), as follows:
For FS entries, the global zone devices are used as special and raw values with a mount point that appears under the root of the non-global zone. The entry to add to the global zone's /etc/vfstab should use the global zone's device paths with the full path to the non-global zone mount point, including the zone path. For example, if the zone looks like:
zonepath=/export/zone1 fs: dir=/export special=/dev/dsk/c0t9d0s6 raw=/dev/rdsk/c0t9d0s6 type=ufsThen the global zone entry in /etc/vfstab should be as follows:
/dev/dsk/c0t9d0s6 /dev/rdsk/c0t9d0s6 /export/zone1/root/export ufs - no -
For device entries mounted by the non-global zone, the following issues must be dealt with when you configure for BMR restoration:
The dynamic mount that is used involves the imported device path under the zone path. For a device that is mounted by /etc/vfstab inside a non-global zone, there are one or more device entries in the zone, such as the following:
zonepath=/export/zone2 device: match=/dev/*dsk/c0t0d0s4
The devices that are listed are in the non-global zone's /etc/vfstab as follows:
/dev/dsk/c0t0d0s4 /dev/rdsk/c0t0d0s4 /local ufs - yes -
This command causes the global zone to dynamically mount.
/export/zone2/dev/dsk/c0t0d0s4 on mount point
/export/zone2/root/local. However, to make BMR automatically recreate the file system, you should add the documenting entry to the global zone /etc/vfstab instead as follows:
/dev/dsk/c0t0d0s4 /dev/rdsk/c0t0d0s4 /export/zone2/root/local ufs - no -
(If you use the device paths relative to the zone path, BMR only recreates the mount point instead of restoring the whole file system.)
The device match should not use wildcards to allow BMR to edit if DDR is used. When the device specification involves a wildcard, if DDR mapping is done that affects the zone (for example, if you unmap or move a file system from one disk to another), BMR is not able to edit the entry. The affected zone's /etc/vfstab is edited, but the device match entries are edited only if the match does not include a wildcard.
For example, change the following entry:
match=/dev/*dsk/c0t0d0s4
The entry must use two device entries, as follows:
match=/dev/dsk/c0t0d0s4 match=/dev/rdsk/c0t0d0s4
If the entries are changed as the example shows, BMR DDR correctly updates the zone definitions and vfstab file.