Nagios Support Forum

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.

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?

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.

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

Still absolutely nothing on this?

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.