cancel
Showing results for 
Search instead for 
Did you mean: 

BMR purge process failed to complete, what next?

jim_dalton
Level 6

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 what it says and fired off the rebuild phase Friday and its still running today, Monday. I cant interrupt it with ctrl-c. I'm interested in getting a bmr db back in action and then continuing on my merry way. Backups hang when trying to access the non-existant bmrdb, contrary to the doc which says they should fail. Catalog backups also hang.

If it means creating a new bmrdb then fine I can live with that.

I've raised a call with Symantec but it might be quicker to get a good answer here: is it safe to kill the nbdb_unload  -dbn BMRDB -rebuild -verbose command?

Whats the backout from this point? If it means creating a new bmrdb then fine I can live with that.

Thanks in advance,Jim

1 ACCEPTED SOLUTION

Accepted Solutions

Jaime_Vazquez
Level 6
Employee

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.

 

 

 

View solution in original post

6 REPLIES 6

mph999
Level 6
Employee Accredited

How big is the BMR database ?

jim_dalton
Level 6

Its 3+Gb.

I should also add that this process also impacts something else....Oracle OIP info. I wasnt expecting that at all.

I have no instances in my oip credentials, theyve all disappeared ...I presume this is because the BMRDB might be a table in a db  and the OIP is another table in same db.

This is a serious design fault if updating the bmrdb affects OIP.

Jim

Nicolai
Moderator
Moderator
Partner    VIP   

A rebuild shoud take no more han 30 minutes. Becuase of urgency you should call Veritas Support.

 

mph999
Level 6
Employee Accredited

Sorry, been snowed under, yes, I'll suggest a call to support as it's fairly urgent.

jim_dalton
Level 6

Update: do not follow additional scenario 2 as per official documentation! This is what Symantec guy told me.

Nice!

Had to kill everything related to netbackup (netbackup stop wouldnt stop, kill_all wouldnt kill all).

Removed all references to BMR db from various configs, netbackup would then start.

Recreated BMR db from scratch.

Jim

Jaime_Vazquez
Level 6
Employee

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.