Basics – Realtime rendered logs and other log options

NetWorker 7.4 saw the introduction of language-neutral logs – raw logs, if you will, in the form of changing daemon.log to daemon.raw. The primary purpose behind this change was to allow customers using one language pack to send a language-neutral log to a support engineer who could then render it locally in a language they could understand.

Many have expressed a dislike for the raw log format – personally it doesn’t bother me, because for the most part I work in Unix environments, so commands to extract only portions of the log either before or after rendering are only a few keystrokes away at any time, and well, I’m a command line person 🙂

There is a facility in NetWorker though to turn on what is referred to as a “realtime rendered log”. One catch: don’t submit the realtime rendered log to your support provider and don’t rely exclusively on it. In some instances, it’s known that messages may be dropped from the realtime rendered log that would be reported if running a manual nsr_render_log against the daemon.raw file.

To setup realtime log rendering, you need to run up nsradmin against the client daemon – either on the NetWorker server or another machine. For example:

[root@nimrod ~]# nsradmin -p 390113 -s nimrod
NetWorker administration program.
Use the "help" command for help, "visual" for full-screen mode.
nsradmin> print type: NSR log
                        type: NSR log;
               administrator: "isroot,host=nox",
                              "user=root,host=localhost",
                              "user=root,host=nimrod";
                       owner: NMC Log File;
             maximum size MB: 2;
            maximum versions: 10;
        runtime rendered log: ;
                        name: gstd.raw;
                    log path: /opt/lgtonmc/logs/gstd.raw;

                        type: NSR log;
               administrator: "isroot,host=nox",
                              "user=root,host=localhost",
                              "user=root,host=nimrod";
                      owner: NetWorker;
            maximum size MB: 2;
           maximum versions: 10;
       runtime rendered log: ;
                       name: daemon.raw;
                   log path: /nsr/logs/daemon.raw;

Here, we have two different log entries – one for NMC and one for NetWorker. If we wanted to just change the NetWorker one, we’d restrict our selection thusly:

nsradmin> print type: NSR log; name: daemon.raw
                        type: NSR log;
               administrator: "isroot,host=nox",
                              "user=root,host=localhost",
                              "user=root,host=nimrod";
                       owner: NetWorker;
             maximum size MB: 2;
            maximum versions: 10;
        runtime rendered log: ;
                        name: daemon.raw;
                    log path: /nsr/logs/daemon.raw;

To update the log setting to generate a rendered log in realtime, all one would have to do is issue the following command:

nsradmin> update runtime rendered log: /nsr/logs/daemon.log
        runtime rendered log: /nsr/logs/daemon.log;
Update? y

To have any change you make here take effect, you need to stop and restart NetWorker.

However, that’s not all you can do here – look at some of those other settings. In particular, “maximum size MB” and “maximum versions”. Personally I think maximum versions is already at a good value – that will keep 10 older copies of the daemon.raw file. (I strongly advocate keeping older copies of log files and ensuring their backups are kept for the lifetime of any backups you may wish to recover from. That way if you have any recovery issues you can, if necessary, recover the server logs from the time the backup was generated.)

The most interesting setting for me is the maximum size MB. The process for NetWorker starting a new daemon.raw file works as follows: IF NetWorker is restarted AND the daemon.raw curently exceeds the maximum size MB THEN rename the existing daemon.raw file AND start a new one.

In the dim dark days of system capacity allocation where asking for a 2GB drive for a backup server was about as well received as asking the board of directors for their cars so you could host your own demolition derby, a maximum log file size of 2MB was seemingly appropriate.

These days I think it’s too low. Now there’s a balancing act here, particularly when you take email and file uploads into consideration. I wouldn’t make it too big, but I would make it bigger – e.g., 10 MB. Reason? Say you have a problem overnight that causes you to restart your NetWorker server and log a case with your support provider. The first thing they’ll ask you to do is send through your daemon.raw; however, in a lot of restart scenarios where issues have occurred, your log file will have grown big enough to require being recreated, so you have to remember to send both. Increasing the default log file size doesn’t guarantee avoiding this, but it does help to ameliorate the possibility.

For convenience then, if you’re going to make the above changes with your log rendering options, I’d also suggest considering increasing the maximum size to at least 5 MB or even 10 MB. (Given file compresability, this shouldn’t pose a problem.)

To do this, you’d enter the command:

nsradmin> update maximum size MB: 10
             maximum size MB: 10;
Update? y

Again, if making changes here you need to restart the NetWorker services for them to take effect.

NOTE: Windows users will need to type paths for the rendered logs with double-backslashes, and in double-quotes. For instance, assuming a default installation location, the path issued might be:

nsradmin> update realtime rendered log: 
"C:\Program Files\Legato\nsr\logs\daemon.log"

Of course, since changes to this affect logging, which in turn affects the ability to diagnose or monitor the backup system, I strongly urge you to confirm following the changes that logging is working.