Hi,

I have done the same. But the syslog back is not happening.

I am planning to upgrade from 3.2.1 to 3.2.2. After doing the same does it will get solved or something more need to be done.

Regards,

I don't understand exactly what you did or what you're trying to accomplish. Please post a screenshot showing exactly what you configured, and please explain exactly the problem you wish to solve.

jc,

Perhaps you could expand on exactly how the RME syslog backup works as I find the documentation a little unclear, which is probably why the initial post is in here too!

It states a backup policy can be configured with a configurable size for the backup file (default 100MB). What I don't understand is when the backup is run, what exactly triggers data to go into the backup file?

Is it the purge data that goes into here?

Thanks

Jed

Purge policy means it goes to the bit bucket when it rolls off the criteria FIFO. Its a scheduled job.

Backup means take the syslog messages which are stored in the database table and dump them to a flat file. Its a scheduled job.

The raw syslog messages exist on your OS in the syslog_info file.

You can manage that file using :

Use Logrot.pl in for versions prior to 3.0

Current versions go to Common Services, Server, Admin, Log Rotation

I understand that backup will dump messages into a flat file. What I don't understand is when will the messages get backed up as there is no schedule. Is it a manual process, is it the purge policy, is it a maximum files size? If it's manual how do you force a backup to take place? I think I'm missing a fundamental point here!

jc potentially implied it was the purge policy "The syslog backup policy controls what happens when syslog messages are aged out of the database"

We manage the file via logrot currently, but it looks like we should check out Log Rotation as we're 3.0, thanks for that pointer.

Jed

RME periodically runs a job which will age old syslog messages out of the database (i.e. delete them). The number of days is configurable in your syslog purge policy. Normally, aged out messages are truly deleted. That is, they are gone forever.

However, you can also choose to configure a syslog backup policy. The backup is run when the purge runs. The messages that would normally be deleted by the purge are dumped into a flat file so that you can maintain an even longer audit trail. The maximum size of this flat file is configurable.

jc,

Thanks, that sounds more like I expected, I don't think that's explained too well in the manuals. Given the purge is in days I presume the job runs on a daily basis so essentially the backup policy is daily.

What happens when you fill the flat file, does it delete it and start again, just stop backing up, work on FIFO?

Is the recommended practice to logrot the backup file or the syslog file (and skip purges)? Does the flat file have anything different in it to the syslog file, they're both text aren't they?

Jed

The purge job runs whenever you want. By default, this is daily. The backup happens at the same time the purge happens.

If the amount of data to be backed up exceeds the max file size, the backup will fail, and send a failure email.

You could rotate and archive the syslog backup file if you wanted. But the recommended procedure is to rotate the syslog.log, and archive the syslog backups to long-term storage.

The syslog backup file is plain text, and contains CSV records similar to what you'd see if you exported one of the syslog reports from RME.

Hi,

I have installed CSM 4.2.2 and RME 4.2. The Log rotation is configured properly.

I need to take the back up of sys.log file which is getting smoething around 2GB per day. So i need to go for log rotation facility.

When i am trying to do manually. its working, but its not working automatically.

Anything what we can do on it.

How have you scheduled logrot.pl to run? Please post your NMSROOT/objects/conf/logrot.conf file.