In this article we’ll explore important guidelines and deployment options for both install types, and provide links to related resources to help you get the most out of them.

Scheduled Backups Note

In the following sections you’ll find guidance on using Nagios XI’s backup/restore capability to facilitate both your testing/development and disaster recovery servers.

If you choose the Local option for your Scheduled Backups, we recommend that you use a mount point on a remote mount, rather than a local directory path on your production XI server itself. This will ensure that you will still have access to the backups in the event of production server failure. Enter the mount point in the Location field of the Local tab of the Scheduled Backups menu to set this up.

We also recommend that you create a mount point to the same remote mount on your DR server so that you can access it for regular disaster recovery testing, and in the event your production server goes down.

Testing & Development

Purpose and Guidelines

Your testing and development (T&D) install enables you to test things like new Nagios XI versions, scripts, plugins, and wizards, as well as operating system or OS component updates (such as dnf update or a PHP upgrade), before rolling them into production.

Your T&D server must not be used for production host and service monitoring or notifications.

Deployment Options

There are a variety of approaches you could take to duplicate your Production environment in T&D, such as:

1. Back Up Production, Restore to T&D

To create the T&D instance using this approach, back up your production system and restore it on your test server to ensure it is similar or identical to your production system. Refer to the following documents in the Nagios XI Admin Guide for full installation and backup/restore instructions:

• Manual Installation Instructions
• How To Back Up & Restore Your Nagios XI Server

2. VM Cloning

If you are using a hypervisor such as VMware or Proxmox, another option is to clone your production system to make an exact copy. The exact steps will vary depending on your hypervisor, so you’ll need to check your vendor documentation or coordinate with your hypervisor admins if you’re uncertain of how to proceed.

Important: Disabling Checks

Regardless of the approach you choose, it is critical that your T&D system is not being used for any checks or notifications unless you are actively testing a specific potential change or scenario for a short time.

To disable checks and notifications on your T&D server, navigate to:

Admin > Monitoring Engine Status

In the Monitoring Engine Process dashlet, click on the “X” to the right of the following Processes:

• Active Service Checks
• Active Host Checks
• Notifications

The Value icon for all three will change from green to red. Once they are red, the XI instance will no longer perform host/service checks or send notifications.

Disaster Recovery

Purpose and Guidelines

The disaster recovery (DR) instance is used to take over production monitoring in the event that your production XI fails.

The DR instance must be in non-operational mode except when it assumes production operation. The only exception to this important policy is that your DR instance can be used to actively monitor your production XI server and notify you of problems.

Deployment Options

1. Hot DR Spare

To create a “hot” disaster recovery spare, install a fresh version of XI on a new, clean Linux installation, making sure the XI version is the same as the production instance.

• Use the DR instance to check that the production XI is running. The Nagios XI Server Wizard is an excellent option for this. Make sure that your production XI server is the only thing being checked and notified on unless you’ve switched DR to production during a production XI outage.
• Ensure that you maintain the same version of XI on the DR and production instances. If your production instance fails, you can recover the most current backup to your DR server and change the IP address (if using passive checks, since they are configured to send to the address of your production server specifically).
• You’ll regain your production checks and notifications while Nagios Support helps you recover your production instance.
• Make sure you upgrade your DR instance when you upgrade Production so that they are the same version, enabling you to apply your backup to DR in the event of a Production XI issue

2. High Availability

Depending on your business continuity and disaster recovery needs, simply having a DR server in place and recovering from a backup may be enough. Or, you may decide to pursue a High Availability (HA) solution. Define what is important to you in a disaster recovery scenario. Once you have clearly defined goals and outcomes, you can plan appropriately and test. You can find additional details in this guide:
High Availability Options for Nagios XI

We also have a network of global partners, known as the Nagios Partner Network, who offer professional services. If you would like help finding a partner to assist with your HA requirements and implementation, just let us know.

You can contact us directly at sales@nagios.com, we’d be happy to answer questions and help connect you
with a Partner.

Further Reading

You can find further details on the three included installation types, license activation, and license benefits here:

Nagios XI License Information

Nagios XI Best Practices