Syslog Plugin 2.1 backup/restore

[chrisgsmith40]

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

Grateful for the direction!

[netniV]

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]

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]

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]

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! 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'

[netniV]

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