How do I back up and restore the NSP cluster data?

Introduction

The procedures in this section describe how to back up and restore the system data and application databases of an NSP cluster.

Note: The following RHEL CLI prompts in command lines denote the active user, and are not to be included in typed commands:

#—root user
bash$—nsp user

Note: NSP Analytics data, such as the report repository contents, are stored in the PostgreSQL database, so are included in the database backup and restore operations described; no separate backup or restore process is required for Analytics data.

Shared-mode deployments

In a shared-mode NSP deployment, it is strongly recommended that you synchronize the backup and restore operations among the systems in the deployment. See the WS-NOC backup and restore documentation, and Chapter 22, Classic management database administration, as required.

NSP database failure alarms

The NSP raises the following alarms in the event of a suspected PostgreSQL database failure:

Note: The alarms are not auto-clearing, so must be cleared manually.

Critical—the leader database is unresponsive
Major—at least one follower database is unresponsive

Identifying the source of a database alarm

In a shared-mode NSP and NFM-P deployment, the NSP and NFM-P raise similar alarms in response to a database failure.

Before you take action to respond to the alarm, you must identify the system that has raised the alarm, and which database instance is at fault.

The Source Type field of a database failure alarm indicates which system, NSP or NFM-P, has raised the alarm.

The Site ID and Site Name fields identify the following:

NFM-P alarm—the NFM-P main server that raised the alarm
NSP alarm—the faulty PostgreSQL database instance

Note: Regardless of the source system, the Additional Text field contains the IP address of the database instance that is at fault.

For example, the Source Type field of a standby database failure alarm contains “NFM-P”. An operator views the Site Name field, which identifies the NFM-P main server that has reported the fault. The operator then views the Additional Text field, and learns that the standby database associated with the main server has failed.

When a similar NSP alarm is raised, the operator has to view only the Site ID or Site Name field to identify which PostgreSQL database instance is at fault.