NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.
  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Twitter

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Basics – Realtime rendered logs and other log options

Posted by Preston on 2009-07-28

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.

Advertisements

2 Responses to “Basics – Realtime rendered logs and other log options”

  1. Hello, Thanks for all you good posts.
    Speaking about logs, do you know any good log summariser scripts? Right now we are getting 7 emails each day with save group completed.
    It could be nice, if it was just one, even though we are running networker on to servers and at different time at the day.

    • Preston said

      Hi Jesper,

      The logs you seem to be referring to are more the savegroup completion reports. I’d suggest that aggregation of multiple reports is risky, because a backup error may then go unnoticed for a longer period of time.

      If you want more intelligent parsing of savegroup completion reports, one option would be IDATA Tools, a suite of utilities sold by my current employer and which I’m a major contributor too. (On the page I’m referring to, search for point #3 in “Reporting Enhancements” to see an example.) The primary purpose of the ‘idata-notify’ utility in that utility suite is to actually have the subject report the key details you need to know – what group the completion notice is for and what the completion status of the group was.

      (I’m fairly certain there’s other utilities in the same vein out there if you’re looking for a non-commercial solution, too.)

      As for aggregating multiple completion reports so you can view them all at the same time – I have to suggest I’m not a big fan of aggregation if it means delays in when the status information is available, so I’m not aware of anything on that front.

      Cheers,

      Preston.

Sorry, the comment form is closed at this time.

 
%d bloggers like this: