Back Up and Restore NNMi

As an NNMi administrator, develop a plan for NNMi backups.

This topic presents the following sections:

• Overview of NNMi Backup
• Backup Type
• Backup Scope
• Restore NNMi Data
• Back up All Data Periodically
• Back Up Data Before Changing the Configuration
• Back Up Data Before Upgrading NNMi or the Operating System
• Restore File System Files Only
• Back Up and Restore the Embedded Database Only

Overview of NNMi Backup

Use the nnmbackup.ovpl and nnmrestore.ovpl command line tools to do any of the following:

• Back up the NNMi management server and restore data to the same system.

• Back up the NNMi management server and use the nnmrestore.ovpl command to place the backed up configuration records and database records onto another NNMi management server. For example, moving NNMi to another NNMi management server due to a hardware failure on the original server.

  Both systems must have the same type of operating system and NNMi version and patch level.

• Back up the NNMi management server as a safeguard before upgrading the operating system on the server.
• Back up the NNMi management server as a safeguard before updating to a newer version of NNMi.

The back up and restore data might include data from any Network Node Manager i Software Smart Plug-ins (iSPIs) installed in your network environment.

Use the nnmbackupembdb.ovpl and nnmrestoreembdb.ovpl tools to do the following:

• Back up the NNMi management server embedded database and restore data to the same machine.
• Back up the NNMi embedded database and use the nnmrestoreembdb.ovpl command to place the backed up database records onto another NNMi management server.

The following table summarizes backup and restore tools capabilities:

Note the following:

• If you use nnmbackup.ovpl for backup, then use nnmrestore.ovpl to restore the data.
• If you use nnmbackupembdb.ovpl for backup, then use nnmrestoreembdb.ovpl to restore the data.

Before you begin a backup, ensure you have adequate storage space for the backup copy. Verify that you have enough space to store the contents of the directories listed in the following table.

You can compress the files after backup.

The NNMi backup command (nnmbackup.ovpl) copies key NNMi file system data and some or all of the tables in the NNMi Postgres database to the specified target directory.

Each backup operation stores files in a parent directory called nnm-bak-<TIMESTAMP> inside the target directory. You can specify a -noTimestamp option to save disk space. If you use the -noTimestamp option, the parent directory is simply named nnm-bak. When a backup is performed after a previous backup using the -noTimestamp option, the previous backup is renamed nnm-bak.previous, thereby creating a rolling backup. This renaming is done after the second backup is completed to protect against any loss of backup data.

The NNMi backup command can create a tar archive of the backup data, or you can compress the backup files using your own tools. You can then use any appropriate tool to save a copy of the backup.

If your NNMi implementation uses Oracle for the main NNMi database, the NNMi backup and restore commands work with the NNMi file system data only. External database maintenance should be handled as part of the existing database backup and restore procedures.

The back up and restore data might or might not include data from any NNM iSPIs installed in your network environment. Check the documentation that came with each NNM iSPI for details.

See the nnmbackup.ovpl reference page, or the Linux man page, for more information.

Backup Type

The NNMi backup command supports two types of backups:

• Online backups occur while NNMi is running. NNMi ensures that the database tables are synchronized in the backed up data. Operators can be actively using the NNMi console and other processes can be interacting with the NNMi database during an online backup. With an online backup, you can back up all NNMi data or only some of the data according to function, as described in Backup Scope. For the embedded NNMi database, the nmsdbmgr service must be running. For an external database, the backup includes NNMi file system data. NNMi processes do not have to be running to back up an external database.
• Offline backups occur while NNMi is completely stopped. With an offline backup, the backup scope applies to the file system files only. An offline backup always includes the complete NNMi database regardless of the backup scope. For the embedded NNMi database, the backup copies the PostgreSQL database files. For an external database, the backup includes NNMi file system data only.

Backup Scope

The NNMi backup command provides several scopes that define how much NNMi is backed up.

Configuration scope

The configuration scope (-scope config) loosely aligns to the information in the Configuration workspace of the NNMi console.

The configuration scope includes the following data:

• For online backups, only those embedded database tables that store NNMi configuration information.
• For offline backups, the entire embedded database.
• For all backups, the NNMi configuration information in the file system as listed in Configuration Scope Files and Directories.

Topology scope

The topology scope (-scope topology) loosely aligns to the information in the Inventory workspace of the NNMi console. Because the network topology is dependent on the configuration that was used for discovering that topology, the topology scope includes the configuration scope.

The topology scope includes the following data:

• For online backups, only those embedded database tables that store NNMi configuration and network topology information.
• For offline backups, the entire embedded database.
• For all backups, the NNMi configuration information in the file system as listed in the first of the following tables. Currently, there are no file system files associated with the topology scope.

Event scope

The event scope (-scope event) loosely aligns to the information in the Incident Browsing workspace of the NNMi console. Because events are dependent on the network topology related to those events, the event scope includes the configuration and topology scopes.

The event scope includes the following data:

• For online backups, only those embedded database tables that store NNMi configuration, network topology, and event information.
• For offline backups, the entire embedded database.
• For all backups, the NNMi configuration information in the file system as listed in the first of the following tables and the NNMi event information as listed in Event Scope Files and Directories.

All scope

The complete backup (-scope all) includes all important NNMi files and the complete embedded database.          

%NnmInstallDir%\misc\nms\lic

$NnmInstallDir/misc/nms/lic

%NnmInstallDir%\nmsas\server\nms\conf

$NnmInstallDir/nmsas/server/nms/conf

%NnmDataDir%\conf

$NnmDataDir/conf

%NnmDataDir%\conf\nnm\props

$NnmDataDir/conf/nnm/props

%NnmDataDir%\NNMVersionInfo

$NnmDataDir/NNMVersionInfo

%NnmDataDir%\shared\nnm\user-snmp-mibs

$NnmDataDir/shared/nnm/user-snmp-mibs

%NnmDataDir%\shared\nnm\actions

$NnmDataDir/shared/nnm/actions

%NnmDataDir%\shared\nnm\certificates

$NnmDataDir/shared/nnm/certificates

%NnmDataDir%\shared\nnm\conf

$NnmDataDir/shared/nnm/conf

%NnmDataDir%\shared\nnm\conf\licensing

$NnmDataDir/shared/nnm/conf/licensing

%NnmDataDir%\shared\nnm\lrf

$NnmDataDir/shared/nnm/lrf

%NnmDataDir%\shared\nnm\conf\props

$NnmDataDir/shared/nnm/conf/props

%NnmDataDir%\shared\nnm\www\htdocs\images

$NnmDataDir/shared/nnm/www/htdocs/images

In this context, files in the shared directories are those shared with another NNMi management server in an NNMi application failover or high availability environment.

Back Up in an HA Cluster

When using the NNMi backup tool in an HA environment, note the following:

• Perform a backup using the active (primary) system. A backup of the backup (secondary) node is not recommended because configuration files could be out-of-date and no shared disk information would be included because the backup node cannot access to the shared disk.
• The shared disk must be connected to the active node. If using a cron job, verify that the shared disk is mounted.
• Put the system into maintenance mode (so as not to trigger a failover).
• Perform an online backup using the nnmbackup.ovpl script on the active node only.
• Periodically, run an offline backup.

Restore NNMi Data

The NNMi restore script (nnmrestore.ovpl) places the backup data on the NNMi management server. The type and scope of the backup determines what NNMi can restore.

If you use the nnmrestore.ovpl script to place database records on a second NNMi management server, both NNMi management servers must have the same type of operating system and NNMi version and patch level.

Placing the backup data from one NNMi management server onto a second NNMi management server means that both servers have the same database UUID. After you restore NNMi on the second NNMi management server , uninstall NNMi from the originalNNMi management server.

Before uninstalling NNMi, remove any NNMi patches in reverse order, beginning with the most recent patch. The patch removal process varies according to the operating system running on the NNMi management server. See the patch documentation for installation and removal instructions.

• To restore an online backup, NNMi copies the file system data to the correct locations and overwrites the contents of the database tables that were included in the backup. Objects that have been deleted since the backup are restored, and objects that have been created since the backup are deleted. Additionally, any objects that were changed after the backup was taken revert to their state at the time of the backup. For the embedded NNMi database, the nmsdbmgr service must be running. For an external database, the restore includes NNMi file system data only and no NNMi processes must be running.
• To restore an offline backup, NNMi overwrites the Postgres files in the file system, completely replacing the database files with the contents of the backup. For an external database, the backup includes NNMi file system data only.

With the -force option, the nnmrestore.ovpl command stops all NNMi processes, starts the nmsdbmgr service (if restoring from an online backup of the NNMi embedded database), restores the data, and then restarts all NNMi processes.

If the provided source is a tar file, the NNMi restore command extracts the tar file to a temporary folder in the current working directory. In this case, either ensure that the current working directory has adequate storage to support the temporary folder, or extract the archive before running the restore command.

Because the database schema might change from one version of NNMi to the next, data backups cannot be shared across versions of NNMi.

NNMiautomatically resynchronizes topology, state, and status following a restore from backup.

Avoid stoppingNNMiduring the resynchronization. To help ensure resynchronization has completed,NNMi should remain running for several hours following the restore from backup. The actual time required depends on the number of nodes and the volume of state changes and trap data received while performing the resynchronization.

If NNMi must be stopped before the resynchronization is finished, the resynchronization should be run again and allowed to complete.

To perform a manual resynchronization of the entire management server, run: nnmnoderediscover.ovpl –all –fullsync

Same System Restore

You can use the backup and restore commands on a single system for data recovery. The following items must not have changed between the time of the backup and time of the restore:

• NNMi version (including any patches)
• Operating system type
• Character set (language)
• Hostname
• Domain

Different System Restore

You can use the backup and restore commands to transfer data from one NNMi management server to another. The intended uses of different system restoration include recovering from system failure and transferring NNMi to a different system during an operating system upgrade.

Because the NNMi UUID is copied to the target system during the database restore, both source and target systems now appear to be running the same instance of NNMi. Uninstall NNMi from the source system.

Before uninstalling NNMi, remove any NNMi patches in reverse order, beginning with the most recent patch. The patch removal process varies according to the operating system running on the NNMi management server. See the patch documentation for installation and removal instructions.

To create multiple functional NNMi management servers with similar configurations, such as while deploying global network management, use the nnmconfigexport.ovpl and nnmconfigimport.ovpl commands.

For a different system restore, the following items must be identical on both systems:

• NNMi version (including any patches)
• Operating system type and version
• Character set (language)

The following items can differ between the two systems:

• Hostname
• Domain

For a different system restore, the nnmrestore.ovpl command does not copy the license information to the new system. Obtain and apply a new license for the new NNMi management server.

Restore on an NNMi Management Server Upgraded to 10.30

If you take a backup on a management server where NNMi10.30 is newly installed, and then try to restore the backup on a management server where an older version of NNMi is upgraded to the version 10.30, you must perform an additional task before the restore process begins. You must follow the instructions in Configure an Upgraded NNMi Environment to Use the New Keystore.

When you try to perform this type of restore operation without completing the steps in Configure an Upgraded NNMi Environment to Use the New Keystore, the following error messages appear in the boot.log file:

ERROR [Http11Protocol] Error initializing endpoint: java.io.IOException: FIPS mode: KeyStore must be from provider JsafeJCE

Restore in an HA Cluster

Backup and restore work seamlessly in an NNMi HA cluster.

If you take a backup of the NNMi data on an NNMi management server (standalone or HA cluster) that was upgraded to the version 10.30 from an older version, and then restore the data in a newly installed NNMi10.30 in an HA cluster, the NNMi processes fail to start after the restore operation is complete.

When using the NNMi restore tool in an HA environment, note the following:

• Verify that the shared disk is mounted.
• Verify that the system is in maintenance mode.
• Perform the restore using the nnmrestore.ovpl script.

In this scenario, before taking the backup on the management server that was upgraded to the version 10.30 from an older version, perform additional configuration steps provided in Configure an Upgraded NNMi Environment to Use the New Keystore.

Back up All Data Periodically

Your disaster recovery plan should include a regularly scheduled complete backup of all NNMi data. You do not need to shut down NNMi to create this backup. If you incorporate the backup into a script, use the -force option to ensure that NNMi is on the correct state before the backup begins. For example:

nnmbackup.ovpl -force -type online -scope all -archive
  -target nnmi_backups\periodic

If you must recover your NNMi data after a hardware failure, follow these steps:

1. Rebuild or acquire new hardware.
2. Install NNMi to the same version and patch level as were in place for the backup.

3. Restore the NNMi data:

   • If the recovery NNMi management server meets the requirements listed in Same System Restore, run a command similar to the following example:

     nnmrestore.ovpl -force -lic
-source nnmi_backups\periodic\newest_backup

   • If the recovery NNMi management server does not qualify for a same-system restore but meets the requirements listed in Different System Restore, run a command similar to the following example:

     nnmrestore.ovpl -force
  -source nnmi_backups\periodic\newest_backup

     Update the licensing as needed.

Back Up Data Before Changing the Configuration

Perform scoped backups as needed before beginning configuration changes. In this way, if your configuration changes do not have the expected effect, you will be able to revert to a known working configuration. For example:

nnmbackup.ovpl -type online -scope config
-target nnmi_backups\config

To restore this backup to the same NNMi management server, stop all NNMi processes, and then run a command similar to the following example:

nnmrestore.ovpl -force -source nnmi_backups\config\newest_backup

Back Up Data Before Upgrading NNMi or the Operating System

Before making major system changes (including upgrading NNMi or the operating system), perform a complete backup of all NNMi data. To ensure that no changes are made to the NNMi database after the backup is made, stop all NNMi processes and create an offline backup. For example:

nnmbackup.ovpl -type offline -scope all
-target nnmi_backups\offline

If NNMi does not run correctly after the system change, roll back the change or set up a different NNMi management server and ensure that the requirements listed in Different System Restore are met. Then run a command similar to the following example:

nnmrestore.ovpl -lic -source nnmi_backups\offline\newest_backup

Restore File System Files Only

To overwrite NNMi files without affecting the database tables, run a command similar to the following example:

nnmrestore.ovpl -partial
-source nnmi_backups\offline\newest_backup

The command is useful when the NNMi implementation uses Oracle for the main NNMi database.

Back Up and Restore the Embedded Database Only

NNMi provides the nnmbackupembdb.ovpl and nnmrestoreembdb.ovpl commands to back up and restore the NNMi embedded database only. This functionality is useful for creating a snapshot of the data as you experiment with NNMi configuration settings. The nnmbackupembdb.ovpl and nnmrestoreembdb.ovpl commands perform online backups only. At a minimum, the nmsdbmgr service must be running.

See the nnmbackup.ovpl reference page, or the Linux manpage, for more information.

Each backup operation stores files in a parent directory called nnm-bak-<TIMESTAMP> inside the target directory. You can specify a -noTimestamp option to save disk space. If you use the -noTimestamp option, the parent directory is simply named nnm-bak. When a backup is performed after a previous backup using the -noTimestamp option, the previous backup is renamed nnm-bak.previous, thereby creating a rolling backup. This renaming is done after the second backup is completed to protect against any loss of backup data.

Run the nnmresetembdb.ovpl command before restoring data to the embedded database. This command ensures that the database does not contain any errors, thereby eliminating the possibility of encountering database constraint violations. For information about running the embedded database reset command, see the nnmresetembdb.ovpl reference page, or the Linux manpage.

Related Topics

Export and Import Configuration Settings

Archive and Delete Incidents