Forum Discussion

  • Setting up logs in NetBackup

    For a given issue, it may be necessary to gather multiple logs.  This MUST cover the time the issue happens.
    If an aditional log is required, that has to be created, then ALL the logs must be supplied again.
     
    There are two types of logs in NetBackup.  Legacy logs and VX logs.
     
     
     
     
    1) Createing Legacy Logs
    2) Setting Verbose Level for Legacy Logs
    3) Collecting Legacy Logs
    4) Createing VX Logs and setting the log level
    5) Collecting VX logs
     
     
    1) Creating Legacy Logs
    ************************
     
    These are created in either
     
    Unix
    /usr/openv/netbackup/logs/
    /usr/openv/volmgr/debug/
     
    Windows
    <install path>\veritas\netbackup\logs
    <install path>\veritas\volmgr\debug
     
     
    For example to create bptm log, simply create a directory called the <process> name.
     
    mkdir /usr/openv/netbackup/logs/bptm
     
    A newly created log will not log anything /detect a change of verbose level until the process is restarted.  For logs such as bptm, this will be when the next backup runs.  Other logs such as bprm and bpdm may require a restart of the NBU services.  I say 'may', if the process starts a child process, then this would write to a newly created log or pick up a verbose level change.
     
     
    2) Setting Verbose Level for Legacy Logs
    ****************************************
     
    There are two ways this can be done :
     
    (Unix)
     
    To increase the verbose level of all logs (except vault)
    Add the entry VERBOSE = <level> into /usr/openv/netbackup/bp.conf.  <level> is a value between 0 and 5, with 5 being the highest.
     
     
    (Windows)
     
    On the server you are gathering the logs from, run the BAR GUI
    From the File menu, select Client Properties and in the pop-up window, goto the Troubleshooting tab.
    Set General to 2 and Verbose to 5
     
     
    3) Collecting Legacy Logs
    *************************
     
    The log file is simply found in the <process> name directory.  There is one log per day.
     
    The name of the log file will be log.<date>
     
    If you are sending multiple log files in, they will all have the same name.  Please therefore rename the log files to :
     
    <process>.log.<date>
     
     
    4) Createing VX Logs and setting the log level
    **********************************************
     
    These are more complex, and have to be set with specific commands.  NOTE: Some of these logs, for example, 'mds' do NOT create a log file.  Instead the lines are entered in to other log files.  In the case of mds (143), it logs into EMM (111).
     
     
    The vxlogs cover various processes, for example, nbemm, nbrb, nbjm, nbrb, mds
     
     
    To set these up on either Unix or Windows, use this command :
     
    vxlogcfg -a -p 51216 -o <oid> -s DebugLevel=<1-6> -s DiagnosticLevel=<1-6>
     
    For example, to set the EMM and MDS logs to levels 6 and 6 use
     
    vxlogcfg -a -p 51216 -o 111 -s DebugLevel=6 -s DiagnosticLevel=6
    vxlogcfg -a -p 51216 -o 143 -s DebugLevel=6 -s DiagnosticLevel=6
     
     
    To confirm the log level has been set, simply look in the nblog.conf file, which is located in the netbackup diorectory.
    (NOTE: DO NOT EDIT THIS FILE MANUALLY)
     
     
    5) Collecting VX Logs
    *********************
     
     
     
    To collect the vx logs, use the nbcplogs command.  This copies the raw logs, which is the preference of Technical Support.
     
    NOTE:  The destination directory MUST be empty.
     
     
    nbcplogs --no-nbsu -d 2hrs --logs nbemm,nbjm /tmp/logs   (Ex.  Coleect the past 2 hrs of logs, RELATIVE, to when the command is run )
     
    nbcplogs --no-nbsu -s 07/11/2012-10:17:58 -e 07/11/2012-12:17:58 --logs nbjm,nbpem /tmp/logs (Collect the logs between two times -s <start> -e <end>  )
     
    In these examples, the nbpem and nbjm logs would be copied to /tmp/logs
     
     
    For details of using vxlogview please see TN:  http://www.symantec.com/docs/TECH75805

  • This is a very good question. The problem is : NBU is very complex and has quite a lot of logs, and it's not really realistic to try and make a list for every problem that can happen. Unfortunatey, the answer requires an amount of experience. The good news is that having process flows (troubleshooting guide) can help, as well as knowing some troubleshooting skills - for example knowing that a really good place to start is often the details for the failed job in Activity Monitor - here you see how far the job got and quite often it display the name of the error along with the process that had the problem, giving you a starting point. sometimes the answer may be in the log of that process, or sometimes in a process that was communication with that process, and sometimes, believe it or not, it was actually somewhere else ... - so the next troubleshooting skill you need is to start 'somewhere' and hop between processes (hence the previous hint of process flows, so you have an idea of what does what). A more advanced t/shooting method is required for efficient analysis of the vx /unified logs (all the logs that need vxlog commands) - probably the most common being nbemm / nbjm / nbrb / nbemm. These logs are multi-threaded which means you need to be aware of how the process itsef works as you if for example you have 5 jobs running the log lines relating to each different job are all mixed together. So thread 1 might being doing something for job1, but the next line for thread 1 migh be doing something for job3, and thread 2 might take over for the next part of job1. It's very helpful to have a test machine, so you can run a job and look through the working exaplme of the logs to work out what lines to look for - easiest way is to run just the one job, then the majority of lines in the logs will only relate to the one job running and you can then look for 'key works; in the log lines to work out how it is working. NBU 7.6 has a logging feature which I believe advises on what logs are needed for a particular issue - I haven't tried it yet but it sounds like a useful tool. The first step is to learn how to turn on the logs and collect them : There is a brief guide about this in my signature below. This command is very useful - http://www.symantec.com/docs/HOWTO43784