Syslog Plugin 2.1 backup/restore

General discussion about Plugins for Cacti

Moderators: Moderators, Developers

Post Reply
Author
Message
chrisgsmith40
Posts: 7
Joined: Fri Jun 01, 2018 11:02 pm

Syslog Plugin 2.1 backup/restore

#1 Post by chrisgsmith40 » Fri Jun 01, 2018 11:12 pm

Howdy, I am assuming this has been answered, but I can't seem to find the right keywords -

> OLD Virtual Machine: Cacti backup (v 1.1.30, w "mysqldump -l --add-drop-table -u root -p cacti > cacti-drop-20180601a.cacti")
> SCP from OLD to NEW (incl RRAs, Scripts, etc...)
> NEW Virtual Machine: Cacti restore (v 1.1.37, w "mysql -u root -p cacti < ./cacti-drop-20180601a.cacti")

Login into NEW VM, answer the Cacti upgrade prompts, all looks good EXCEPT None of the backed up SYSLOG events are browsable - only the new events coming in.

Actually browsing around via "mysql" I can see data in syslog table, etc...

Admitting, this is a hodge podge backup/restore - so was hoping there's a known hyperlink out there that covers the SYSLOG Cacti Plugin Backup / Restore?

Is some sort of re-index involved? A script I need to run afterwards? Some "timestamp" or "sequence number" that needs to be touched?
Personally rating my skills in the PHP / MYSQL / MariaDB space, I would rate myself a NOOB - probably 0.5 on a 10 scale :wink:

Grateful for the direction! :)

netniV
Cacti Guru User
Posts: 2682
Joined: Sun Aug 27, 2017 12:05 am

Re: Syslog Plugin 2.1 backup/restore

#2 Post by netniV » Sat Jun 02, 2018 11:55 am

If you backed up the tables and installed the same version on the new server, it should just work. If you are seeing new events, these are normally via the incoming table (I believe). The other thing to do is check in the cacti log and php/apache logs to see if there are any errors being recorded.

chrisgsmith40
Posts: 7
Joined: Fri Jun 01, 2018 11:02 pm

Re: Syslog Plugin 2.1 backup/restore

#3 Post by chrisgsmith40 » Sat Jun 02, 2018 6:09 pm

Thanks netniV -

Hmmmm, ok. The SYSLOG Plugins are same version (2.1), but that's about the end of the similarities. Trying to pivot this, would it be advised against the following:

- NEW: (1) Disable then (2) Uninstall SYSLOG plugin
- NEW: Via mysql admin, drop syslog tables.
- NEW: (1) Install then (2) Enable SYSLOG plugin, selecting defaults, so ...
> Database Storage Engine: MyISAM Storage
> Database Architecture: Traditional Table
> Retention Policy: 1 Month
> Partitions per Day: 1 Per Day
(my assumption will be these will get updated anyway during restore)
- NEW: Make sure new SYSLOG events are managed as expected (incoming, etc...)
- OLD: Only (1) Disable SYSLOG plugin
- OLD: Backup the following tables out of cacti database ...

Code: Select all

| syslog                              |
| syslog_alert                        |
| syslog_facilities                   |
| syslog_host_facilities              |
| syslog_hosts                        |
| syslog_incoming                     |
| syslog_logs                         |
| syslog_priorities                   |
| syslog_programs                     |
| syslog_remove                       |
| syslog_removed                      |
| syslog_reports                      |
| syslog_statistics                   |
- NEW: Import those tables into cacti
- Go through those touch points as advised (check in the cacti log and php/apache logs, etc...)

If I'm missing something big on this backup / restore (eg: another table?), grateful for the follow-up!

netniV
Cacti Guru User
Posts: 2682
Joined: Sun Aug 27, 2017 12:05 am

Re: Syslog Plugin 2.1 backup/restore

#4 Post by netniV » Mon Jun 04, 2018 6:09 am

DO NOT UNINSTALL THE PLUGIN ON THE OLD SERVER

I say that in upper case to be very clear. Most plugins will remove the tables they create if uninstalled for two reasons. 1, to ensure that no stray and large tables are left behind redundantly taking up space. 2, to provide a method to cleanly reinstall a plugin. So to be clear, uninstalling a plugin will result in losing all configuration/data.

Looking over your steps you have correctly said disable on old. But other people may miss it so I'm making it clear.

That aside, I don't think your missing much. But I'll have to look over this tonight to make sure I didn't miss something in your explanation of the problem.

chrisgsmith40
Posts: 7
Joined: Fri Jun 01, 2018 11:02 pm

Re: Syslog Plugin 2.1 backup/restore

#5 Post by chrisgsmith40 » Thu Jun 07, 2018 4:42 pm

Thanks so much for engaging!

I was going to prep a step-by-step of what I tried, but wasn't necessary.
For my issue, the "Old Cacti" stored SYSLOG tables inside the "CACTI" database.
While, disable/remove/install/enable the SYSLOG plug-in on "New Cacti" stored SYSLOG tables inside a "SYSLOG" database.
Once I sorted that, all my SYSLOG events were there! :D So, #TwoThumbsUp and #HappyGeek


<Feel free to ignore, just research notes>
Honestly, haven't followed pros/cons why the two differences (will assume aligned around performance tuning).
I did do a quick search and re-found I'm guessing stale notes (couldn't quickly find the syslog.sql in my Plugin install) here ... https://docs.cacti.net/plugin:syslog.config

Another look at my /var/www/html/cacti/plugins/syslog/config.php - and, yes, there IS the "flag" called $use_cacti_db, mine is set to 'false' :roll:

netniV
Cacti Guru User
Posts: 2682
Joined: Sun Aug 27, 2017 12:05 am

Re: Syslog Plugin 2.1 backup/restore

#6 Post by netniV » Sat Jun 09, 2018 6:23 am

The main reason for having them separated is that the large amount of records, inserts/deletes/searches against the SYSLOG tables can affect the main cacti DB performance. So, to make sure that the core isn't affected you have a separate instance which can be on the same or separate server. tt also allows you to granularly apply different settings to each DB for performance, etc

Post Reply