GuidesREST APISlack CommunitySupport PortalOpsview 6.8+ Documentation
Hey! These docs are for version 6.4, which is no longer officially supported. Click here for the latest version, 6.7!

Below is a list of some of the common tasks System Administrators may need to perform

## Backing up Opsview Monitor Databases and Configuration

  • Edit `/opt/opsview/coreutils/etc/opsview.conf` to check or set the correct backup destination in the variable `$backup_dir`


## Backing up Opsview Monitor Database Only
  • Ensure opsview.conf is correct

The _runtime_, _odw_ and _reports_ databases may be backed up in the same way.
## Restoring From a Database Backup
Identify the required image to restore from (location is held in `$backup_dir` variable within the `opsview.conf` file if using a full backup rather than database only).

If you need to upgrade the database schema because you have restored a backup from an earlier release of Opsview, you can run the following:

## Setting MySQL root Password
We recommend you set a password for 'root' user

## Granting Access to Remote User
For making remote database connections to Opsview Data Warehouse:

## Fixing Damaged Database Tables
If a database table is damaged, you may get error messages like:

A common cause is running out of space on /var partition where mysql writes its table files:

To repair table (from MySQL client - note that you'll need enough disk space free for MySQL to make a new copy of the damaged table as a .TMD file):

To check all databases, you can use the following as the mysql root user:

## Using a Read-Only Database
Opsview has the ability to use a separate, read-only replicated database, for certain REST related database queries. This will, for the most part, increase the responsiveness of the main REST API calls that Dashboard uses, and reduce the load on the master database.
This relies on MySQL replication to keep the data in sync between the master and its collectors. See [external documentation](🔗) on how to setup MySQL replication.
To avoid unnecessary replication on a MySQL slave system, you should add the following parameter to the collector my.cnf:

To configure Opsview, we need to allow Opsview Web to connect to the replicated database.  Here, we assume you have already replicated at least the _opsview_ and _runtime_ databases. You'll need to make sure that the _opsview_ user exists on the slave MySQL database server, and have _SELECT_ access to the _opsview_ and _runtime_ databases, respectively. You should allow them to connect from the Opsview Monitor master database server.
For example:

`/opt/opsview/coreutils/etc/opsview.defaults` has database related '_ro_' variables. Copy these to `opsview.conf` and change them to point to the slave MySQL server.
Any variables that aren't copied into opsview.conf or changed will default to their respective values from the non-read-only database. Be sure to double-quote the variable values (see the other database related values around that area in opsview.defaults for some examples).
You can obtain the encrypted versions of the passwords by running `/opt/opsview/coreutils/bin/opsview_crypt`
Restart opsview-web: 'service opsview-web restart'. Dashboard and other parts of Opsview Monitor should now be using the collector MySQL database for most status views.
### Troubleshooting
If Opsview Monitor doesn't start back up after a restart, check that you've changed the values of the correct '_ro_' variables in opsview.conf.