Forum Discussion

jim_dalton's avatar
jim_dalton
Level 6
9 years ago

BMR purge process failed to complete, what next?

Hello forumites Ive been following this process to cleanup my bmrdb: https://support.symantec.com/en_US/article.TECH211811.html   I'm doing the additional scenario 2. So I believed wha...
7.6
Backup and Recovery
Configuring
NetBackup
Patch
Recovering
Solaris
Troubleshooting
  • Jaime_Vazquez's avatar
    Jaime_Vazquez
    9 years ago

    OK. Need some background on this first.  What is the NBU version in place on the Master? Why the need to do the purge process?  How big are the BMRDB files. Of interest, the sizes of the BMRDB.db file and the BMR_DATA.db file, which should be the largest of the group.

    OK, some BMRDB process explanation:

    Client configurations are imported into the BMRDB as part of any client backup with the BMR option enabled. The process is supposed to overlay the existing "current" configuration with the new "current" configuration. Old copies of 'current' should not exist in the BMRDB, with one exception. If there is a PTR task in the BMRDB, that version of restore configuration is kept in the DB as it is tied to an active restore task. It gets a slightly different config name and is typically not visible.

    The BMR_DATA.db file, especially for environments with a large Windows client base, will be the largest of the group, as it holds copies of the device driver files captured for each Windows client. Boot Servers and their SRT information are only key entries in the DB. The actual SRT files and file systems are resident on the Boot Server.

    That being said, client information is constantly being updated in the BMRDB as part of any backup. Client registration is trivial. As such, it is by far a faster method to just rebuild/reinitialize the BMRDB on the Master. To help I wrote:

    Rebuilding the BMR database (BMRDB)
    http://www.symantec.com/docs/TECH212536

    A freshly rebuilt set of BMRDB files is about 100 MB in total size. Naturally, as clients are added, the files grow.  

    Now, doing things this way has a few "shortcomings".
    1. Entries for copied configurations, Point In Time configurations, and Discovered configurations will be lost.
    2. The article describes how to reset Boot Servers and reload SRT information from same said Boot Servers. Pointers to media (ISO) SRT are not captured or recoverable. New entries will need to be done by creating new media boot SRT.

    Re-initializing the BMRDB to a new state takes a very short time (just a few minutes). Services need to be running. All clients will automatically register on any FULL or INCR backup that follows.  There is no data loss issues as part of this, for client recoveries, as there is no backup image information in the BMRDB.

    And, for item 2 above for Boot servers, there is a slightly different method on how to capture all Boot Server information (including all SRT information) and reload them in one step, per Boot Server. But, that would need assistance from a support person as the method makes use of a hidden utility that is for use by support persons only. It is not a customer level command.

     

     

     

Jaime_Vazquez's avatar
Jaime_Vazquez
Level 6
9 years ago

OK. Need some background on this first.  What is the NBU version in place on the Master? Why the need to do the purge process?  How big are the BMRDB files. Of interest, the sizes of the BMRDB.db file and the BMR_DATA.db file, which should be the largest of the group.

OK, some BMRDB process explanation:

Client configurations are imported into the BMRDB as part of any client backup with the BMR option enabled. The process is supposed to overlay the existing "current" configuration with the new "current" configuration. Old copies of 'current' should not exist in the BMRDB, with one exception. If there is a PTR task in the BMRDB, that version of restore configuration is kept in the DB as it is tied to an active restore task. It gets a slightly different config name and is typically not visible.

The BMR_DATA.db file, especially for environments with a large Windows client base, will be the largest of the group, as it holds copies of the device driver files captured for each Windows client. Boot Servers and their SRT information are only key entries in the DB. The actual SRT files and file systems are resident on the Boot Server.

That being said, client information is constantly being updated in the BMRDB as part of any backup. Client registration is trivial. As such, it is by far a faster method to just rebuild/reinitialize the BMRDB on the Master. To help I wrote:

Rebuilding the BMR database (BMRDB)
http://www.symantec.com/docs/TECH212536

A freshly rebuilt set of BMRDB files is about 100 MB in total size. Naturally, as clients are added, the files grow.  

Now, doing things this way has a few "shortcomings".
1. Entries for copied configurations, Point In Time configurations, and Discovered configurations will be lost.
2. The article describes how to reset Boot Servers and reload SRT information from same said Boot Servers. Pointers to media (ISO) SRT are not captured or recoverable. New entries will need to be done by creating new media boot SRT.

Re-initializing the BMRDB to a new state takes a very short time (just a few minutes). Services need to be running. All clients will automatically register on any FULL or INCR backup that follows.  There is no data loss issues as part of this, for client recoveries, as there is no backup image information in the BMRDB.

And, for item 2 above for Boot servers, there is a slightly different method on how to capture all Boot Server information (including all SRT information) and reload them in one step, per Boot Server. But, that would need assistance from a support person as the method makes use of a hidden utility that is for use by support persons only. It is not a customer level command.