Forum Discussion

JustN's avatar
JustN
Level 4
11 years ago

Restarting NetBackup Master / Applying Changes

Good Morning-

My environment:

  • 1x NetBackup 7.6.0.2 Master Server running on RHEL 6.5
  • 12x NetBackup 7.6.0.2 Media Servers running on Windows Server 2008 R2 SP1
  • 4x NetBackup 7.6.0.2 Clients running on mixture of Windows Server 2003/2008

This NetBackup configuration seems to work very well, I don't have any major complaints... A few minor annoyances, but so far, so good.

That said, I have a concern/question that I want to share, just to make sure I do not have an underlying problem that needs to be resolved!

I have found that in order to apply most, if not all configuration changes on the Master server, a reboot (of the Master server) is required in order to apply and activate the changes.

For example this weekend I added a bandwidth limitation for one of my client subnets through the GUI, but could never get the limit to enforce. I even manually submitted the job multiple times, but still, the limitation would not apply. After rebooting the Master Server, I then submitted the jobs once again and now the bandwidth limit works great!

My question is, is this normal? If so, for a busy NetBackup environment (I don't have this, at least not yet), how do you find time to reboot the Master server when making a configuration change?

As a related question... I realize that a reboot of the Master server is a bit extreme, I believe that a simple "service netbackup stop"/"service netbackup start" should be sufficient... But, I have found this to be unreliable. In many cases, most of the NetBackup processes will stop (after a "service netbackup stop"), except for the NetBackup EMM process -- I have seen NBEMM run for 10 - 15 minutes after all of the other processes exit. If you quickly issue a "service netbackup start" command, the other NetBackup processes will start, but not function correctly because the NBEMM process is in a wierd state.

In the end, I find that just rebooting the server is quicker and ensures that all of the processes come back up cleanly.

Any thoughts or suggestions appreciated!

JP

7.6
Backup and Recovery
Basics
Configuring
NetBackup
Tip-How to
Troubleshooting
UNIX
  • RiaanBadenhorst's avatar
    RiaanBadenhorst
    11 years ago

    Hi,

     

    It really depends what you're changing. If the change relates to a process that get generated during each backups, lets say for instance a buffer size change for the tape devices, that would not require a restart. The next bptm process just needs to start a backup.

    Other configuration changes like updating settings on the master server can usually be affected by running bprdreq -rereadconfig. So its really depends on what you're changing.

     

    If you want to get all the processes down on your linux master use bp.kill_all located in the goodies folder.

     

    Wait for all the processes to stop by themselves if you can. Might take a while but let them do there thing.

  • RiaanBadenhorst's avatar
    RiaanBadenhorst
    Level 6
    11 years ago

    Hi,

     

    It really depends what you're changing. If the change relates to a process that get generated during each backups, lets say for instance a buffer size change for the tape devices, that would not require a restart. The next bptm process just needs to start a backup.

    Other configuration changes like updating settings on the master server can usually be affected by running bprdreq -rereadconfig. So its really depends on what you're changing.

     

    If you want to get all the processes down on your linux master use bp.kill_all located in the goodies folder.

     

    Wait for all the processes to stop by themselves if you can. Might take a while but let them do there thing.

  • SymTerry's avatar
    SymTerry
    Level 6
    11 years ago

    Like Riaan said,

    bprdreq -rereadconfig. Although, as per TECH9932, This command will only detect and incorporate some bp.conf configuration changes. Many NetBackup configuration changes, such as adding or changing a SERVER entry, require a complete stop and start of the NetBackup daemons. If the bp.conf configuration change does not take effect, then the NetBackup daemons must be restarted. 

    Also just to make sure, you should not have to reboot the physical server.

  • mph999's avatar
    mph999
    Level 6
    11 years ago
    My belief is that even a busy system shoulld have some idle time during a 24 period to allow for maintenance. If that can't be accomplished, then you need another server. I've honestly lost count of the number of times what is really a 'none issue' has become a major issue because there is no spare time on a system, be it for a restart, or time to rerun failed jobs, or catch up on missed duplications.
  • Jaime_Vazquez's avatar
    Jaime_Vazquez
    Level 6
    11 years ago

    A  running NBU process may not see the changes made on the Admin GUI as it typically loads its running environment and settings when the process is instantiated into memory. The command 'bprdreg -rereadconfig" will cause the bprd process to reload the environment found in the "bp.conf" file and making the changes made there active.  

    Rebooting a server should not be a required action.  At worst, stopping and starting all services should be sufficient to make the changes active.

    Riann's post has it correct. Invoking ../netbackup/bin/bp.kill_all followed by ../netbackup/bin/bp.start_all will do the deed. You can also use "netbackup stop" and "netbackup start" found in the ../bin/goodies directory.

     

     

  • sdo's avatar
    sdo
    Moderator
    11 years ago

    I'm with Martin (mph999) on this one.

    When we consider that many even minor changes in Windows (from updates) require a reboot, then this tells us something about the complexity of modern software.  Even OpenVMS needed a reboot after some config changes, but then such things are always down to the design of a 'system' as a whole - and the latent comlexity of testing.  When one stops and thinks about the design and scale of NetBackup these days, it's a little unfair to think of it as just another Backup Application - IMO, it's so rich, wide and deep now; that really we should think of it as a BOS (Backup Opertating System) (just think how many commands and switches there are!), almost like some OS used to be refered to as a DOS (Disk Operating System) - and there were many other Disk Operating Systems, even on large mainframes, not just MS-DOS.  Anyway, they were all cutting edge at the time, and so is NetBackup now.

    So, back to Martin's point... If you are experiencing ever decreasing time for manintenance down time, even just a few minutes (for a small system) (sometimes an hour and a half to restart a large environment) to restart the appliaction, then your environment is slowly painting you in to a corner, which is never a good place to be.

    To be clear about something, I have yet to some across a "known" situation where a change to a NetBackup application configuration element requires a whole system reboot.  It's usually changes to other elements on the perifary (even just at the edge of the O/S that meets the NetBackup boundary) that require reboots.  Usually a "clean" restart of the application/system/environment is enough - and remember 'environment' doesn't just mean the master server, sometimes this covers all media servers too.

    We've all gone through the phase of thinking - why doesn't that config change take effect immediately - believe me, we all have.  I guess it's just something that we've since learned to live with - the benefits of such a wide scope of configuration flexibility outweigh such annoyances.