Snapshot restore
Snapshot restore
Is there an easy way to restore a config snapshot in the event that a config apply fails? I'm trying to debug a config import issue and need an easy way to blow away the nagios QL db.
Re: Snapshot restore
Looking at the documentation, another method looks to do a restore of the DB data from;
/store/backups/mysql
/store/backups/postgresql
Has anyone else used this method?
/store/backups/mysql
/store/backups/postgresql
Has anyone else used this method?
Re: Snapshot restore
Do you want to blow away the NagiosQL database on a configuration failure? Nagios XI will automatically roll-back the exported config files that are used for monitoring when it detects a problem. The NagiosQL database, however, is left untouched so you can make changes and resolve errors.
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Ethan Galstad
President
Ethan Galstad
President
Re: Snapshot restore
I have the same conundrum. I'm not concerned about the flat files being replaced, I want to roll back the database to a clean config and start the import process over so I don't have issues with duplicate imported definitions (overwrite doesn't seem to be working.) Is there not a simple way to restore the database to a backup? If you import configuration errors there's no better way to resolve it than fix each entry in the database as opposed to rolling back and importing a proper configuration? Any advisement would be helpful.
Thanks
Thanks
Re: Snapshot restore
Still absolutely nothing on this?
Re: Snapshot restore
Databases can rollback transactions, however once a transaction is committed this is not possible.
The solution I've always used is to avoid databases, SQL in particular but LDAP and XML are also not well suited for managing configurations. Revision Control System(rcs, cvs, svn, git, "ect") are all vary well suited to managing configuration changes and all have the ability to rollback changes, even more useful is the ability to compare/review changes made between revisions and remove a single change, even if it was made a long time ago. Both raising awareness of what exactly is configure removing the need in most cases to rollback changes and in other cases making a simple 'undo' possible.
As for what you can be done with NagiosQL, It would be much easier to dispose of(shut it down and/or pause, turn off) the existing install and start anew. Sadly this is the trade-off made when working with most GUI(s), so it's become and accepted practice.
Your other options include removing tables from the database and reloading them from an SQL dump of a pristine(made from an install image) database dump. I believe such a dump would have to be included as part of the install tarball.
The solution I've always used is to avoid databases, SQL in particular but LDAP and XML are also not well suited for managing configurations. Revision Control System(rcs, cvs, svn, git, "ect") are all vary well suited to managing configuration changes and all have the ability to rollback changes, even more useful is the ability to compare/review changes made between revisions and remove a single change, even if it was made a long time ago. Both raising awareness of what exactly is configure removing the need in most cases to rollback changes and in other cases making a simple 'undo' possible.
As for what you can be done with NagiosQL, It would be much easier to dispose of(shut it down and/or pause, turn off) the existing install and start anew. Sadly this is the trade-off made when working with most GUI(s), so it's become and accepted practice.
Your other options include removing tables from the database and reloading them from an SQL dump of a pristine(made from an install image) database dump. I believe such a dump would have to be included as part of the install tarball.