Rebuilding the BMR database (BMRDB)

Problem

BMRDB files will grow over time as entries are added to it.  However, it will never automatically shrink as entries are deleted. Under some circumstances entries in the BMRDB can become corrupted, which can cause problems when BMR operations are being performed. Lastly, collapsing an oversized BMRD can help increase access performance on a running server. This is a recommended action to take ahead of an upgrade that goes to a new major release, such as from 7.0.X to 7.5.0.0.

Cause

Normal database insertions can cause the database files to grow over time.  Deletions however do not decrease the physical size of the files.

Solution

Prior to taking any actions, create a safe backup copy of the BMRDB files. If the data is not useful or not desired, you can skip this step.

/usr/openv/db/bin/nbdb_backup -dbn BMRDB -online $SAVE_DIR

$SAVE_DIR can be any directory path you have locally.
 
Detailed steps to take.
 
All actions are done on the Master Server via command line. All commands exist in the normal NetBackup "bin" directory.
Unless otherwise noted, NetBackup services must be running but no BMR enabled backups should be active.
The example command invocations below are in Unix/Linux format for file names. 
The example invocations are identical on Windows Servers, using Windows install file paths.
 
1. From the Administration console, under Bare Metal Restore Management node "Tasks", cleanup any and all active tasks for BMR. IMPORTANT!
  
2. Rebuild/reinitialize the BMRDB files. The command will reinitialize all BMRDB files to their starting sizes and values. All existing entries are removed..
 
Method 1:

bmrsetupmaster -redo -force

Method 2:

Stop the BMRDB database connection.
     nbdb_admin -stop BMRDB
Change directory to location of the NBU database.
    /usr/openv/db/data
    $inst_path\NetBackupDB\data
Delete the four BMR named files.
Edit the 'vxdbms.conf' file and remove the BMRDB entry line.
Change directory to the database CONF directory.
    /usr/openv/db/CONF
    $inst_path\NetBackupDB\CONF
Edit the file "databases.conf" and delete the BMRDB entry line.

The state of BMRDB will be identical to what is seen for a freshly installed server.
Rebuild the BMRDB files with:

     bmrsetupmaster

3. Check the state of the new BMRDB using the "nbdb_ping" command.

    nbdb_ping -dbn BMRDB

   If not connected, reconnect with:
  
   nbdb_admin -start BMRDB

4. Verify that the new BMRDB was rebuilt to the latest SCHEMA.
 
   bmrs -o query -res database -table CurrentVersion
 
The NBU release of the Master Server should be the working SCHEMA value.
Check the file sizes in the database "data" directory. They will be back to default and should be smaller than the original files.
 
5. Recover Boot Server and SRT entries into new BMRDB. 

For all previously registered BMR Boot Servers, log into that server and run command "bmrsetupboot -register". Once completed the server name will be visible in the Administration GUI, under the Hosts->Boot Server selection.
 

Run command "bmrsrtadm"
Use the option to copy/import an SRT into BMR.  Specify the "import" option.
All previously registred SRT files will be in the directory/folder originally designated to hold them.  Each SRT will have its own directory/folder by the same name as the SRT. As an example, if the SRT creation directory was named "/SRT", there will exist directories in there with names of the SRT itself. 
For each SRT to be imported, specify the path to the directory/folder that holds the file "srtData.xml". For SRT name, it is highly recommended to reuse the same SRT name as before. That way the SRT name and directory holding it will still match.
Note: Check the file "srtData.xml" for any entries that are marked "LOCKED_WRITE". Do not register any such SRT entries.

Media SRT (ISO based) need to be rebuilt to get their entry into the BMRDB. Boot Servers do not hold any information that shows their existence. Use the 'bmrsrtadm' or Boot Server Assistant to do this.
 
6. Restart the Administration Console. Under the Bare Metal Restore "Hosts -> Boot Server" tab, verify that you can see all of the Boot Servers. Invoking the command "bmrs -o list -res Boot Server" will display all registered Boot Servers and their associated information and database ID number.  All registered SRT information is visible under the "Resources -> Shared Resource Tree" selection.  They can be displayed from command line on the Master Server with "bmrs -o list -res SRT".
 

7. Clients will register normally on the next BMR enabled backup for each of them. The backup can be a regularly scheduled policy based backup or a manual enabled backup. It can be a FULL or an INCR backup. The client registration portion is always the first activity of the backup, ahead of any actual NBU backup streams.  The action of the actual NBU backup is not a requirement for client registration. If invoked manually, once the BMR import function is complete, the client is registered and the backup job itself can be canceled with no problem. Verify this whenever possible by viewing the entries, using the Administration Console or from command line with "bmrs -o list -res Client". For Winsdows clients, the import process will also reload the client device driver files as before.  They can be seen either from the Administration Console, under "Resources -> Packages" or from the command line using the command "bmrs -o list -res Package".
 
If it necessary to do a BMR operation for a client that is not registered but is not in a position to do a backup, the following steps are required:
 
1. Do an alternate client restore of the client’s BMR configuration file from a recent backup image.  It can be from a FULL or an INCR backup. The file path is:
 
/usr/openv/netbackup/baremetal/client/data/bundle.dat (Unix/Linux client)
 
$inst_path\netbackup\baremetal\client\data\bundle.dat (Windows client)
 
If the Master is Unix/Linux and the client is a Windows client, the bundle.dat file copy must first be restored to any Window system and then copied to the Unix/Linux Master.  This is due to an restore problem of the image itself, which will have special Windows stream header imbedded. If the Master is a Windows system, the file can go directly to the Master Server. Copy the file to any local directory.
 
2. Execute this command on the Master (OS dependent):
 
bmrs -o import -res Config -path $PATH/bundle.dat   (Unix/Linux Master)
 
bmrs -o import -res Config -path $PATH\bundle.dat   (Windows Master)
 
Regardless of how the clients were registered, use the Administration Console and verify that the client is now visible as a registered BMR client. You can also use, on the Master Server, one of the following two commands:

bmrs -o list -res Client
bmrs -o list -res Config
 
The above steps cannot recover the following BMR database entries/components:

Copied configurations
Discovered configurations
Manually imported Device Drivers

All actions taken to originally create them will need to be performed again.

Applies To

NetBackup Master Server with BMR Option at any released and supported level.