A long time ago, in a NetWorker far, far away, all the output of a savegroup was included in the notification it generated. Eventually, this was determined to be too problematic – when it worked, it was good, but if a group had some major issue (or someone turned on the verbose flag), notification messages could be extremely large.
This led to the “X lines suppressed” message that would appear in savegroup notifications, and for a while you could establish an option in /nsr/debug to turn message suppression off if you really wanted the full details of the savegroup.
Eventually though, for reasons unknown to sensible people, such suppression-disabling disappeared entirely, until /nsr/tmp/sg turned up, which would contain a list of directories named after savegroups and the most recent notifications generated by those groups. After a while, savegroup suppression was turned off for the details saved into that directory.
With the release of NetWorker 8, the tmp/sg group has been moved to a more logical location – /nsr/logs/sg, and the filenames cleaned up somewhat.
While there’s a command line tool now (nsrsgcomp) which will pull back old savegroup notifications, if you want to get to the real guts of the messages, you can go browse the /nsr/logs/sg directory:
Listing any directory will get you a selection of files such as the following:
By themselves, the filenames are hardly interesting. However, because each message that appeared in a recent savegroup is stored in these files, it does make plain text searching fairly straight forward:
If you’re searching for errors to see how commonly they’ve occurred across all your clients for instance, it becomes as simple as going into the /nsr/tmp/sg directory then running a search for the string across “*/*” – all files in all subdirectories. Simple, quick, and efficient.
If you’re wanting to increase the number of days that messages are kept for, edit the NetWorker server properties (not the server’s client instance) and increase the “Jobsdb retention in days”:
Be careful though – it’s generally recommended not to have this set to too long a period of time. (I’m somewhat curious if this restriction/recommendation has been removed with the adoption of SQLite for the jobs database). If you want to search back longer, you may want to setup a process which automatically copies these files into another directory for longer term preservation – or for casual searches, recover older versions of the directory to alternate locations.