It's possible (and recommended) to back up the configuration for your Nagios component using the Configuration-> Control-> Commit screen. But where do you go to restore these backups? What do you need to do to ensure a backup that is made in an older version will work when you restore it to a newly upgraded version?
The restore process is not currently available within the UI. The bookshelf (help screens) cover this in the section called "Home > SYSTEM MAINTENANCE > Backup and Restore", but this section is long and general. The following procedure is a simplified version:
- On the command line, change to the backup directory:
- Look for your backup directory by date. The directories are named for the date of the backup, for example, August 10, 2010 at 09:05_04 am would be:
The way configurations are backed up affords you the chance to back up before you commit. This means that whatever changes you were about to make are what is backed up. If you want to revert your most recent changes, you have to restore from one backup before the date of the changes you wish to revert.
- cd to the directory containing the backup you want to restore. You will see a file in this directory named "monarch-<date and time stamp>.sql, for example:
- To restore, for example, the monarch-2010-08-10_09-05-04.sql file, type:
- You will now have the configuration from the backup made August 10, 2010, at 09:05:04am loaded in the configuration database. It will not be active until you commit the configuration with the user interface using Configuration -> Control -> Commit.
GroundWork versions often contain changes to the data schema for the configuration database. This means that the backups you made on older versions can't be used on the later versions unless you migrate them.
Fortunately, the migration is easy. Follow the procedure above, until you have the backup restore, but have not re-Committed the changes. At the command line, type:
You will see the follwoing messages on the screen:
If you forget this step, you will probably have issues using the Configuration application, since the code will be expecting the updated database schema. Also, there have been some changes to the way performance graphs are processed, so the migration takes the standard configuration and updates it. If you have a non-standard configuration for performance data processing, it is left alone.