Welcome to docs.opsview.com

Backing Up Opsview

Opsview has a nightly housekeeping job, invoked from cron, that runs at 03:11 evey night. This includes backups.

The scope of the backups is to be able to restore a system as soon as possible on the same (or similar) hardware and operating system.

You will need to design your own backup strategies for long term archival of data.

Opsview nightly backups

A cronjob for the nagios user will be present on the master server called rc.opsview cron_daily. This runs daily housekeeping tasks, including the backing up of various parts of Opsview.

Note: The backup should reside on a different disk/filesystem to /usr/local/nagios, otherwise there is no redundancy at this level. You will also want the backup transferred to another server, to provide redundancy in a server failure.

Long term data is not necessarily backed up. See Data not covered by nightly backup for more details of data that should be backed up by local policy.

There are backup variables in opsview.defaults:

$backup_dir            # which directory to store the backups. Default ''/usr/local/nagios/var/backups''
$backup_retention_days # number of days worth of backups to keep. Default 30

Note: All files older than $backup_retention_days within $backup_dir are removed, not just opsview backups.

Invoking a Backup

You can invoke an adhoc backup by running as the nagios user:

/usr/local/nagios/bin/rc.opsview backup

Data included by nightly backup


The Opsview configuration database is backed up. It is also backed up after every reload.

From Runtime, only the nagios_objects and nagios_instances table is backed up. This is required to ensure consistency with the primary keys for all the various objects in the database with ODW.


This includes:

  • /usr/local/nagios (including Nagvis)
  • /usr/local/opsview-web
  • /usr/local/nagios/var - if this is a symlink, it will follow it

Note: Other than /usr/local/nagios/var, symlinks are not followed - if you setup any other symlinks, you should ensure those are backed up appropriately.

Files may change as they are being backed up, but these should only be transient information (like log files or rrd files).

The backup excludes:

  • /usr/local/nagios/var/backup
  • /usr/local/nagios/var/mrtg
  • /usr/local/nagios/var/ndologs
  • /usr/local/nagios/nmis/database
  • /usr/local/nagios/snmp/all
  • /usr/local/nagios/tmp

Data not covered by nightly backup


Again, due to size constraints, Runtime is not backed up. If you use the data within Runtime and require it to be stored for recovery, you are recommended to use a 3rd party tool to back this up too. The configuration tables in Runtime are generated by Opsview and Nagios® Core, so will not need to be restored.

Only the nagios_objects table in Runtime is saved as this is required to ensure primary key consistency with ODW.


NMIS stores its data in /usr/local/nagios/nmis/database. Due to size, this is not stored as part of the nightly backup. If you have a need to retain this data, you are recommended to use a 3rd party tool to back up this directory.


MRTG RRD files are stored in /usr/local/nagios/var/mrtg. Due to size, this directory is not backed up as part of the nightly backup. If you need to retain this data, you are recommended to use a 3rd party tool to back up this directory.


This assumes that you are restoring from the backup files generated by the nightly backup. This also assumes that you are restoring to the original Opsview server. If you are interested in migrating Opsview to a different server, see the migration document instead.

su -
/etc/init.d/opsview stop
/etc/init.d/opsview-web stop
cd /
tar --gzip -xvf /{path_to_backups}/nagios-files-{datestamp}.tar.gz
mysql -u root
mysql> drop database opsview;
mysql> drop database runtime;
mysql> drop database reports;
mysql> exit
gunzip -c /{path_to_backups}/opsview-db-{timestamp}.tar.gz | mysql -u root -p{mysqlrootpassword}
gunzip -c /{path_to_backups}/runtime-db-{timestamp}.tar.gz | mysql -u root -p{mysqlrootpassword} runtime
gunzip -c /{path_to_backups}/reports-db-{timestamp}.tar.gz | mysql -u root -p{mysqlrootpassword}
su - nagios
/usr/local/nagios/installer/upgradedb.pl  # Check upgrades are okay. See below if error
exit # back to root
/etc/init.d/opsview gen_config
/etc/init.d/opsview-web start

Note: If you get “No database selected”, notice that you have to specify runtime as the target database when restoring nagios-runtime-db-{timestamp}.tar.gz.

Note: If you get an error which says:

Upgrading Opsview part of Runtime database
DB at version 2.7.0
DBD::mysql::db do failed: Table 'opsview_contact_services' already exists [for Statement "CREATE TABLE opsview_contact_services (

See the FAQ entry for resolution.

Full Opsview offline backup

You can do a full offline backup by taking the following steps:

  • Shutdown Opsview on master
  • Backup filesystem /usr/local/nagios on Opsview master
  • Backup filesystem /usr/local/opsview-web on Opsview master
  • Stop mysql on database server
  • Backup mysql data files

This will backup all data regarding Opsview so you can restore to this point in time.

Exporting data in CSV format

Data can be exported from MySQL in CSV format for use with spreadsheet software and other databases.

The following example can be run from the Unix shell. It exports Opsview service check configuration into a file called: /tmp/servicechecks.csv

echo "USE opsview; SELECT * INTO OUTFILE '/tmp/servicechecks.csv' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\"' LINES TERMINATED BY '\n' from servicechecks;" | mysql -u root -p