1. Network Analytics Data Director Disaster Recovery Guide
  2. Introduction

1 Introduction

This document describes procedures to perform the backup and restore for the Oracle Communications Network Analytics Data Director (OCNADD) deployment. The backup and restore procedures will be used in the disaster recovery of the OCNADD. The OCNADD operators can take only the OCNADD instance specific database and required OCNADD Kafka metadata backup and restore them either on the same or a different Kubernetes cluster.

The backup and restore procedures are helpful in the following scenarios:

  • OCNADD disaster recovery
  • OCNADD cluster migration
  • OCNADD setup replication from production to development or staging
  • OCNADD cluster upgrade to new CNE version or K8s version

The OCNADD backup contains the following data:

  • OCNADD database(s) backup
  • OCNADD Kafka metadata backup including the topics and partitions information

Note:

If the deployed helm charts and the customized ocnadd/values.yml for the current deployment are stored in the customer helm or artifact repository, the helm chart and values.yml backup are not required.

Figure 1-1 OCNADD Backup and Restore


OCNADD Backup and Restore

OCNADD Database(s) Backup

The OCNADD database consists of the following:
  • Configuration data: This data is exclusive for the given OCNADD instance. Therefore, an exclusive logical database is created and used by an OCNADD instance to store its configuration data and operator driven configuration. Operators can configure the OCNADD instance specific configurations using the Configuration UI service through the Cloud Native Core (CNC) Console.
  • Alarm configuration data: This data is also exclusive to the given OCNADD instance. Therefore, an exclusive logical database is created and used by an OCNADD Alarm service instance to store its alarm configuration and alarms.
  • Health monitoring data: This data is also exclusive to the given OCNADD instance. Therefore, an exclusive logical database is created and used by an OCNADD Health monitoring service instance to store the health profile of various other services.

The database backup job uses the mysqldump utility.

The Scheduled regular backups helps in:

  • Restoring the stable version of the data directory databases
  • Minimize significant loss of data due to upgrade or rollback failure
  • Minimize loss of data due to system failure
  • Minimize loss of data due to data corruption or deletion due to external input
  • Migration of the database information from one site to another site

OCNADD Kafka Metadata Backup

The OCNADD Kafka metadata backup contains the following information:

  • Created topics information
  • Created partitions per topic information

Prerequisites

Before you run any disaster recovery procedure, ensure that the following prerequisites are met:

  • cnDBTier must be in a healthy state and available on a new or newly installed site where the restore needs to be performed
  • Automatic backup should be enabled for OCNADD.
  • Docker images used during the last installation or upgrade must be retained in the external data storage or repository
  • The ocnadd/values.yaml used at the time of OCNADD deployment must be retained. If the ocnadd/values.yaml file is not retained, it is required to be recreated manually. This task increases the overall disaster recovery time.

Important:

Do not change DB Secret or CnDBTier MySQL FQDN or IP or PORT configurations during backup and restore.

Disaster Recovery Impact Areas

The following table shares information about impact of OCNADD disaster recovery scenarios:

Table 1-1 OCNADD Disaster Recovery Scenarios Impact Information

Scenario Requires Disaster Recovery or Reinstallation of CNE? Requires Disaster Recovery or Reinstallation of cnDBTier? Requires Disaster Recovery or Reinstallation of Data Director?
Scenario 1: Deployment Failure

Recovering OCNADD when its deployment is corrupted

No No Yes
Scenario 2: cnDBTier Corruption No Yes No

However, it requires to restore the databases from backup and Helm upgrade of the same OCNADD version to update the OCNADD configuration. For example, change in cnDBTier service information, such as cnDB endpoints, DB credentials, and so on.

Scenario 3: Database Corruption

Recovering from corrupted OCNADD configuration database

No No No

However, it requires to restore the databases from old backup.
Scenario 4: Site Failure

Complete site failure due to infrastructure failure, for example, hardware, CNE, and so on.

 Yes Yes Yes
Scenario 5: Backup Restore in a Different Cluster

Obtaining the OCNADD backup from one deployment site and restore it to another site

No No No

However, it requires to restore the database.

References

While performing disaster recovery procedures, you may refer to the procedures defined in the following existing documents:

  • Oracle Communications Network Analytics Data Director User Guide
  • Oracle Communications Network Analytics Data Director Troubleshooting Guide
  • Oracle Communications Network Analytics Data Director Installation Guide
  • Oracle Communications Cloud Native Environment and Installation Guide
  • Oracle Communications Cloud Native Core Disaster Recovery Guide
  • Oracle Communications Cloud Native DBTier Installation Guide