cancel
Showing results for 
Search instead for 
Did you mean: 

Purging logs from <install_path>\VERITAS\NetBackup\logs?

NB_noob
Level 3

These logs are killing the Master Server and causing the EMM database to crash.

 

I've just cleared some space, but now I need to purge these logs.

 

Is it safe to purge some of these logs (the oldest ones in the directory) or even compress them?

 

thanks.

Message Edited by NB_noob on 07-09-2008 06:37 AM
Message Edited by NB_noob on 07-09-2008 06:48 AM
4 REPLIES 4

Andy_Welburn
Level 6

A few excerpts from Admin Guide & Troubleshooting Guide. (for 6.5)

 

Legacy logging
For those processes that use legacy logging, you must first create a log directory for each process to be logged. A logging level selection on the Logging properties page does not enable logging.
Create the NetBackup legacy log directories in:
■/usr/openv/netbackup/logs/process_name (UNIX)
■install_path\NetBackup\logs\process_name (Windows) On a Windows server, you can create all of the NetBackup debug log directories at one time by double-clicking mklogdir.batin the following directory: install_path\NetBackup\logs\

Create the Media Manager legacy log directories in:
■/usr/openv/volmgr/debug (UNIX)
■install_path\Volmgr\debug (Windows)
For more information about legacy logs, see the NetBackup Troubleshooting Guide.

 

Controlling legacy logs
NetBackup retains legacy debug logs for the number of days that are specified in the Keep Logs global attribute (28 days by default). Then it deletes them.
For instructions on how to change Keep Logs, see the NetBackup Administrator’s Guide, Volume I.
A robust logging feature is also available for controlling the size of debug logs that certain NetBackup processes create.
See “Legacy logging file rotation (robust logging).”
Debug logs can grow very large. Enable them only if unexplained problems exist.
Delete the logs and the associated directory when they are no longer needed.

 

 

 

You should be able to safely delete these logs and their associated directories, but I would ensure that nothing is running at the time so that logs are not being updated when you delete them.

 

If you require the logs, you can also move them from the default location. Follow this TechNote:

http://seer.entsupport.symantec.com/docs/282865.htm

There's also one on Unified logging:

http://seer.entsupport.symantec.com/docs/282865.htm

NB_noob
Level 3

thanks Andy.

 

i've just had to put out a bushfire and make sure jobs keep running.

 

i'll probably just look at compressing them for the time being. thanks.

 

Saluki_Fan
Level 3

I had a problem where the logs were filling up the file system containing the NetBackup catalogs, putting the catalogs in danger of an out of space condition. I had a NOM alert activated that informed me that there was less than 10% of space left for the catalogs to grow into, so I had time to resolve the condition before it became a problem. In my case, I was not using the legacy logs. But I was using the unified logs. Here's what I did to solve it on a Solaris (UNIX) NetBackup server. My unified logs were in the /usr/openv/logs/ directory. I took the NetBackup 6.0 Troubleshooting class which gave me the knowledge to resolve the problem.

 

Deleted all the unified logs with this command which deletes the last 30 days of logs.

     vxlogmgr -d -n 30

 

Displayed the current unified logging configuration settings with this command.

     vxlogcfg –l –p 51216 –o 111

 

Set the DebugLevel and DiagnosticLevel for unified logging to 0 which is minimum logging level.

     vxlogcfg –a –p 51216 –o ALL –s DiagnosticLevel=0 –s DebugLevel=0

 

Made a new directory for NetBackup unified logging which pointed to a file system separate from the file system containing the NetBackup catalogs. And I set the LogDirectory configuration setting to point to the new directory. Now, if I set unified logging to higher logging levels, the logs will not take space away from the catalogs.

     vxlogcfg –a –p 51216 –o ALL –s LogDirectory=/var/netbackup/logs

Another thing I did but probably didn't have to do was to reduce the number of logs kept from 3 to 1. Now it keeps only one log file per log type and deletes the rest. A new log file will replace the old log file. At the time, I was desperate to reduce the danger to the catalogs and probably went overboard. If we have problems in the future for which I need to refer to the logs, I can change the configuration settings and, hopefully, will be able to recreate the problem.

     vxlogcfg –a –p 51216 –o ALL –s NumberOfLogFiles=1

Omar_Villa
Level 6
Employee

here is the guide to configure logs retention and more

 

http://seer.entsupport.symantec.com/docs/279590.htm

 

 

regards