Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

BMR backup is not happening when BMR is enable,With out BMR backup is Running

Created: 23 Sep 2013 • Updated: 02 Oct 2013 | 5 comments

Hi

We have run the backup for the server its in queued for long time.But backup is not even hapenning

Wen ever we are uncheck the BMR ,the backup is running fine.But i need to run the backup through the BMR only ,can you please suggest ASAP

NB version (Master) :6.5.6

NB version (Client) : 6.5.6

Operating Systems:

Comments 5 CommentsJump to latest comment

rishi_raj_gupta's picture

Hi,

Please verify that you have enabled BMR Master server setup on your NBU master server?

This can be done by verifying if "bmrd.exe" process is running on your master server ("bmrd" process for Unix).If bmrd not running, this can be done by running "bmrsetupmaster" CLI from netbackup/bin dir.

If bmrd is running, please confirm the output of below CLI on your NBU master server, running it from netbackup/bin dir.

bmrs -o query -r database -table currentversion

Regards,

Rishi Raj

virankumar's picture

bmrd is running

O/p

----

bmrs -o query -r database -table currentversion
 

4 vCurrentVersion Entries:
    Id = 1
    Name = SCHEMA
    Version = 6.5.6.0
    Checksum = 1855
    DateTime = 1274172676

    Id = 3
    Name = PREVIOUS_SCHEMA
    Version = 6.5.0.0
    Checksum = 1813
    DateTime = 1242639431

    Id = 4
    Name = PREVIOUS_SCHEMA
    Version = 6.5.3.0
    Checksum = 1827
    DateTime = 1272554237

    Id = 5
    Name = PREVIOUS_SCHEMA
    Version = 6.5.5.0
    Checksum = 1855
    DateTime = 1274172676
 

rishi_raj_gupta's picture

>> We have run the backup for the server its in queued for long time.But backup is not even hapenning

Hi,

I need to ascertain if BMR backup is triggered but taking a lot of time (or hanging) to complete or if the BMR backup process not even triggered. Please confirm.

Also, in order to confirm if the problem is with BMR or not, may I ask you to run following commands manually. Please enable debug level 6 logs on your client & master server.

1. To ensure that the BMR is able to collect the system info & is not hangling while collecting information, please run following command on your client system from under netbackup/bin

bmrsavecfg -infoonly

With above command you will get the file under netbackup\baremetal\client\data\bundle.dat

2. If above command successful, move the above bundle.dat into you master server and run below command from master server's netbackup/bin folder:

bmrs -o  import -r config -path <path-to-bundle.dat>

The above two steps ensure if any BMR process is causing the backup to hang. Please collect "bmrsavecfg" log from client & "bmrd" log from master server, if any step fails.

Thanks,

Rishi Raj

Marianne's picture

You REALLY need to upgrade your environment - NBU 6.5 ran out of support a year ago.

LOTS of fixes and improvements since 6.5.x version.....

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Jaime_Vazquez's picture

First of all, I fully agree with Marianne's response. NBU 6.5 is EOSL.

Now, some background on what is happening at backup time:

When the NBU job scheduler starts a backup job from a policy where the BMR option is enabled, it performs two actions:

1, It does a START_NOTIFY script action to the client to be backed up.  This causes that client to run the process "bmrsavecfg".  It passes along command options that describe policy and backup information which will be embedded into the client configuration file.
2. It start up "bpbrm" in a "BMR enabled" mode.  This becomes the "Master" job for the backup on the Activity Monitor. This job stays active for the entire backup process and reports its own status code. This "bpbrm" process waits for the client configuration file that will sent to it by the client.  When it receives the packet file, it then sends it to the "bmrd" Master process (parent id=1). The "bmrd" process spins off a child process by the same name and hands off the data to be inserted into the BMRDB, using normal database service. The master process waits for the child process to complete and gets its status code, which it then passes back to the waiting "bpbrm" process.  All of this is visible in the job details of the Master backup job.

Once "bpbrm" has gotten the "bmrd" status code, it then fires off all of the actual NBU backup streams, as per the policy, in the same manner as if BMR was not in play. Again, the difference is that this job stays active until the entire backup completes. Once the entire backup completes, it captures the status codes and exits.

So, what needs to be looked at in your environment is what job is being queued on the Activity Monitor? Look at the job process and job details information for the queued job. The BMR portion of the backup does not require any resources to run but will not start up until the resources for the backup job itself are ready.

The "bpbrm" job can get "hung" under two possible conditions:
1. It is waiting for the client to send it the "bundle.dat" configuration file.
2. It is waiting for the completion of the configuration import process by "bmrd".

The "bmrd" process can get "hung" if there are issues with database services during the import of the configuration data. This can happen if a significant number of BMR enabled jobs are fired off simultaneously and run in parallel.  There will be multiple "bpbrm" jobs running on the Master, one per backed up client.  This in turn will cause multiple "bmrd" child processes to be instantiated, one per backup client, and all of them trying to connect to the BMRDB through the database service at the same time.  Place enough of these on the server at the same time and you can see that the database update becomes a significant choke point. And, as all of this data transfer is happening through shared memory, it can really peg the CPU on most any server. 

The bmrsavecfg process can get "hung" on the client it is having problems getting responses from the OS as it queries the components of the system needed for the configuration file.  The usual suspect in this are disk drives that it "sees" and tries to interrogate for data, such as size and geometry. This process is fairly light weight and should complete in a minute or so. To see the running time, run "bmrsavecfg -infoonly" from the command line and see how long it takes to complete. If there are problems or errors, they will display locally.

Configuration import on the Master is also fairly straight forward and should run in a minute or so as well (longer for Windows clients than for Unix/Linux - the device driver packages need to be inserted as well). Doing this manually when the server is not under load will not show if there is database contention at normal backup times. You can see the normal run time by executing "bmrs -o import -res Config -path $full_path_to_bundle.dat_file" from the command line on the Master. The "bundle.dat" file needs to be copied from the client to the Master at some location (any place is good).

So, back to your situation.  Your first step of diagnostics is the actual queued job and the process information and details it has, as seen on the activity monitor. Take it from there and gives us an update.