Migrate between matching Monitor versionsAlways ensure the Monitor versions on the systems you're migrating between matches exactly. Importing backup files made on an older, or newer, version of Monitor is not supported.
The purpose of this document is to serve as a guide for customers who are running appliances with EL6 and wish to upgrade their operating system to EL7, through migration to a virtual machine or a new installation on the same machine.
Note that it is not possible to upgrade an installation of CentOS6 in place. A new installation of CentOS7 needs to be set up on either another server (virtual or physical) or replacing the current installation on the same server.
Step 1: Upgrade
If you are running an old version of OP5 Monitor, first use yum to update to the latest version available through the repositories. Automatic updates stay in the same mainline: this means that if you are on version 7.x there will not be an automatic upgrade to version 8.
# yum update
If you are on an older version, it may not support EL7, so updating OP5 Monitor first is always recommended.
Step 2: Verify your current OP5 Monitor version
# cat /etc/op5-monitor-release
Important: When making and restoring op5-backup files, the versions have to match exactly. Do not import a backup file that was created on another version of OP5 Monitor.
Step 3: Disable notifications and stop OP5 Monitor
You can do this through the Web GUI:
“Manage > Process Information > Options (right corner) > Operations > Disable Notifications”
However, this is a "runtime setting", so to be safe, we recommend you disable notifications directly in naemon.cfg followed by a restart of Monitor:
For more information about naemon.cfg, see Main Configuration File Options.
Step 4: Run the backup
# mon stop
# op5-backup --migrate
From the help:
System migration to the next major version of CentOS release
No other options is needed. If you are using this on a 32 bit
system you will automaticly perform an archetecture change.
This is the only time when the 'migrate' module is in use.
If you do not use the 'migrate' module you need to specify
mode manually with -m charch if you are moving from a 32 bit
To make a backup to be used when migrating to a new major system
where you want to restore on the same server after you have
reinstalled the operating system. This backup will include all
backup modules available. Which means that you will have not only
the op5 products in the backup but also a system backup that will
be used in the restore. This will not include all kinds of system
settings. Just the ones needed by op5 products
For more information on what the different modules back up, inspect the scripts under:
Step 5: Inspect the backup log and verify the backup
The logs from op5-backup runs can be found in:
For example, something like:
# grep -i error backup-20200311-094153.log
Verify the backup file:
# tar tvf <backup-file>
# op5-restore -l -b <backup-file>
Step 6: Transfer the backup file to your new server
Expectations:At this point, your new server should already be running EL7. Your new server could be the same physical machine, a new virtual machine, or something else. Since there are several different ways to install EL7 we will not list the steps you need to take in this guide. Consult the documentation of RHEL or CentOS for the installation procedure. You should also have the same version of Monitor installed as listed in step 2. You can download OP5 Monitor here.
Step 7: Restore the backup file
Run from consoleThe following commands should be run from a virtual console in vCenter or a physical console on the server, as the op5-restore procedure will overwrite network configuration.
If you are migrating to a new server, shut down the old server before running the restore procedure, as it will re-use the IP configuration of the old server.
Before running the restore procedure, manually verify that the new server has the IP address you expect and that the required ports are open. OP5 Monitor normally requires two-way communication on ports 22 (SSH), possibly 161 (SNMP checks) and 15551 (Merlin) to all nodes.
# op5-restore -b <backup-file>
When the restore is complete, reboot the server.
Verify functionality in the GUI. Verify e-mail and SMS notifications, if configured.
If checks are failing, make sure that you have installed any necessary dependencies that may have existed on the old server, for example, the VMware SDK, Dell OMSA, or any custom Perl modules.
If everything looks all right, go ahead and re-enable notifications again:
Ninja Web GUI: “Manage > Process Information > Options (right corner) > Operations > Enable Notifications”
You may also need to re-enable notifications in naemon.cfg.