Welcome to docs.opsview.com

Differences

This shows you the differences between two versions of the page.

opsview4.6:backups [2014/09/09 12:19] (current)
Line 1: Line 1:
 +====== 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|Data not covered by nightly backup]] for more details of data that should be backed up by local policy.
 +
 +There are backup variables in [[opsview4.6:configuration_files|opsview.defaults]]:
 +<code>
 +$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
 +</code>
 +
 +**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:
 +<code>
 +/usr/local/nagios/bin/rc.opsview backup
 +</code>
 +
 +==== Data included by nightly backup ====
 +=== Databases ===
 +The Opsview configuration database is backed up. It is also backed up after every reload.
 +
 +The Reports database is backed up.
 +
 +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.
 +
 +=== Files ===
 +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 ====
 +=== ODW ===
 +Due to its size, ODW is not backed up as part of the Opsview nightly backups. It is recommended that you use a 3rd party tool to save the historical data in ODW to a separate system. You can use mysqldump, but beware that you are backing up the same data every time and that the tables are locked during the backup. You may be able to run incremental backups with a different tool.
 +
 +=== Runtime ===
 +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 ===
 +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.
 +
 +If you have a distributed environment, you will need to backup these directories on the slave too. In a clustered slave environment, the directories are rsync'd, so a single node in a cluster will be sufficient.
 +
 +=== MRTG ===
 +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.
 +
 +If you have a distributed environment, you will need to backup these directories on the slave too.
 +
 +=== Slaves ===
 +Opsview slaves collect data for Nagios Core, so results are sent back up to the master. Slaves do have Nagios Core logs stored in /usr/local/nagios/var/archives and these will be stored locally and housekept appropriately. No automatic backup is run for these.
 +
 +There are MRTG and NMIS data locally stored. If you want those stored long term, you will need to backup those parts separately.
 +
 +===== Restore =====
 +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 [[opsview4.6:migratinghardware|migration document]] instead.
 +
 +**Note**: If you have a slave system, when opsview starts, it will try to initiate communications with the slave.
 +
 +<code>
 +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
 +</code>
 +
 +**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:
 +<code>
 +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 (
 +</code>
 +
 +See the [[opsview4.6:faq#i_get_a_database_upgrade_error_during_an_upgrade|FAQ entry]] for resolution.
 +
 +===== Full Opsview offline backup =====
 +You can do a full offline backup by taking the following steps:
 +  * Shutdown Opsview on master
 +  * Shutdown Opsview on slaves
 +  * Backup filesystem /usr/local/nagios on all Opsview servers
 +  * 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
 +<code>
 +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
 +</code>
Navigation
Print/export
Toolbox