Video Screencast Help

Netbackup BMR Tasks stuck in queued

Created: 05 Mar 2014 | 3 comments

HI,

Netbackup Env: Windows Server 2008 R2 + 4 media servers,

Master + Media NB version 7.5.0.7

I followed the process as HERE but:

My target machine si same architecture, 64bit but with different harware(disimilar restore).

For a disimilar restore, when I create Prepare to Discover task, the job in taks panel is in queued all time, more likely stuck, same for Prepare to Restore.

If I Prepare to Discover a server already backed-up with BMR option enable in policy, same thing, Prepare to Discover Job in Task pannel is stuck in queued mode. (please see the picture). (the server here is 100% connected, backup job 100% successful).

Aswell if I workarround and get BRM start on the target machine:

that means I mount the srtCD-boot in the target, I start a Generic BMR Restore and I discover the target from itself, then I can see the discovery of target machine.

after this, next step is when the restore is on going but only C:\ drive restore itself, the System State doesnt.

I checked in the Activity Monitor and only one job here. The restore on the target fails ofcourse and no other retore job occur for System State.

This is a bug? Why this happens, what do you think I should test/do.

Operating Systems:

Comments 3 CommentsJump to latest comment

Mark_Solutions's picture

BMR tasks do not go active or complete until the activated process has completed and notification has been received by the Master Server.

If any of what you have done has not completed or not sent the right message they will not complete

You can cancel and delete them if you wish

A system State restore does not come active until after the reboot - or are you saying it never actually did that part of the restore?

You say you did a prepare to discover but then ran a backup of the system ... that just allows you to copy that clients configuration to the other clients .. a prepare to discover uses the BMR boot media / PXE boot to run the discovery and does not need a backup or a NBU client installing to do it - that is probably why the BMR job never completed as you have not actually "discovered" the server yet

Hope this helps

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

Jaime_Vazquez's picture

The entire BMR restore process debug log is created on the Master Server. Look in the ..\logs\bmrrst\$client_name\MMDDYY.log file for detailed restor progess.  If the restore of the C: failed, the process termninates and nothing else gets done.  The failure should have been noted on the console of the client as well as the debug log.

The status of the recovery in the TASKS section is mostly informational and is really not required to be there. A BMR restore or discovery for a Windows client does not need to have a Prepare to Restore or Prepare to Discover done ahead of the boot, unless it is a network boot. The states should be Queued -> Restoring -> Finalizing -> Complete.

The bmrrst program on the client sends a message to the Master to upate the task status.  Again, it is mostly informational.

Jaime_Vazquez's picture

Ensure that the DSR process is correctly set up.  The configuration used for all of the work needs to reflect the target hardware system.  See details in this TECH article:

Doing a Dissimilar System Restore (DSR) to new hardware for Windows clients using Bare Metal Restore (BMR) on NetBackup 6.X and 7.X releases.
http://www.symantec.com/docs/TECH52394

What is the hardware vendor and model for the source server and for the target hardware?

Required Windows NIC and MSD device driver support in the SRT and the BMRDB is described in this article:

Windows Device Driver Requirements for Bare Metal Restore (BMR) 
http://www.symantec.com/docs/TECH181674
 

And I again want to point out that detailed process log information is written to the Master Server when things get started up on the cleint.  The path is $INST_PATH\logs\bmrrst\$CLNT_NAME\MMDDYY.log.  It should reflect activity and interactions between the client and the Master Server for the taks settnigs.