Restoring orchestration data

Restore IBM® Cloud Pak for Network Automation by specifying the backup orchestration data to use for the recovery cluster in a YAML file, then apply that YAML file.

Before you begin

Note: This task includes only the steps to restore orchestration data, such as assembly and resource packages. It does not include the steps to restore application logging data, such as microservice logs. For information about restoring application logging data, see Restoring application logging data.

Verify that the backup orchestration data is good, as described in Verifying backup orchestration data.
Shut down the IBM Cloud Pak for Network Automation instance, as described in Shutting down IBM Cloud Pak for Network Automation by using the CLI or Shutting down IBM Cloud Pak for Network Automation by using the console.

Procedure

Stop the ibm-tnc-orchestration-controller-manager pod by running the following commands:
```
oc get deploy
oc edit deploy ibm-tnc-orchestration-controller-manager
```
Change the value of the replicas property to zero, as shown in the following sample YAML:
```
spec:
    progressDeadlineSeconds: 600
    replicas: 0
```
Save the deployment, then wait for the ibm-tnc-orchestration-controller-manager to shut down.
Run the following command to delete the PostgreSQL cluster:
```
oc delete cluster cp4na-o-postgresql
```
Wait for the PostgreSQL cluster and pods to shut down.
Check that the PostgreSQL cluster and pods shut down correctly. Run the following command in your namespace to verify that the cluster is shut down:
```
oc get cluster
```
If no PostgreSQL cluster resources are found in the IBM Cloud Pak for Network Automation instance namespace, the cluster is shut down.
To verify that all PostgreSQL microservices are shut down, run the following command in your namespace:
```
oc get pods | grep postgresql
```
If the following pods are not running, then the microservices are shut down: cp4na-o-postgresql-1, cp4na-o-postgresql-2, and cp4na-o-postgresql-3.

Copy the following YAML format data into a YAML file, for example, cp4na-postgres-restore.yaml.

apiVersion: postgresql.k8s.enterprisedb.io/v1
kind: Cluster
metadata:
  name: cp4na-o-postgresql
spec:
  bootstrap:
    initdb:
      database: app
      owner: app
  description: Postgres cluster instance for orchestration instance default
  imageName: <image_name>
  instances: 3
  postgresql:
    parameters:
      max_connections: <max_connections_value>
      shared_buffers: <shared_buffers_value>
  primaryUpdateStrategy: unsupervised
  resources:
    limits:
      cpu: <limits_cpu_value>
      memory: <limits_memory_value>
    requests:
      cpu: <requests_cpu_value>
      memory: <requests_memory_value>
  storage:
    size: <size_value>
    storageClass: <storage_class>
  bootstrap:
    recovery:
      backup:
        name: <backup_name>
      recoveryTarget:
        targetTime: <backup_target_time> # Format: yyyy-mm-dd hh:mm:ss

Tip: If you want to recover the system to a specific time in the past rather than to the latest available WAL recovery point, specify that time in the bootstrap.recovery.backup.recoveryTarget.targetTime key.

Update the keys in the YAML file with the values that your IBM Cloud Pak for Network Automation installation uses. To find out what those values are, use the following commands:

imageName

oc get orchestration <instance_name> -o jsonpath='{.spec.advanced.postgres.image}' -n <cp4na_namespace>

postgresql.parameters.max_connections

oc get orchestration <instance_name> -o jsonpath='{.spec.advanced.postgres.parameters.maxConnections}' -n <cp4na_namespace>

postgresql.parameters.shared_buffers

oc get orchestration <instance_name> -o jsonpath='{.spec.advanced.postgres.parameters.sharedBuffers}' -n <cp4na_namespace>

resources.limits.cpu

oc get orchestration <instance_name> -o jsonpath='{.spec.advanced.postgres.resources.limits.cpu}' -n <cp4na_namespace>

resources.limits.memory

oc get orchestration <instance_name> -o jsonpath='{.spec.advanced.postgres.resources.limits.memory}' -n <cp4na_namespace>

resources.requests.cpu

oc get orchestration <instance_name> -o jsonpath='{.spec.advanced.postgres.resources.requests.cpu}' -n <cp4na_namespace>

resources.requests.memory

oc get orchestration <instance_name> -o jsonpath='{.spec.advanced.postgres.resources.requests.memory}' -n <cp4na_namespace>

storage.size

oc get orchestration <instance_name> -o jsonpath='{.spec.storage.postgres.storageSize}' -n <cp4na_namespace>

storage.storageClass

oc get orchestration <instance_name> -o jsonpath='{.spec.storage.postgres.storageClassName}' -n <cp4na_namespace>

Update the following backup keys in the YAML file:

Key	Update
`bootstrap.recovery.backup.name`	Add the PostgreSQL backup object that you want to restore. Add the PostgreSQL backup object, not the orchestration backup object. Run the following command to find the name of the PostgreSQL backup object: `oc get backup`
`bootstrap.recovery.backup.recoveryTarget.targetTime`	To recover the latest available WAL recovery point, remove this key. To recover a backup from a specific time, enter the time in this format: `yyyy-mm-dd hh:dd:ss`

Restore the cluster by applying the YAML content that you created in 4. To apply the YAML file, run a command similar to the following example:
```
oc apply -f cp4na-postgres-restore.yaml
```
If you are not in the namespace where you installed IBM Cloud Pak for Network Automation, use the -n option to specify the IBM Cloud Pak for Network Automation namespace.
Wait until the PostgreSQL cluster is restored. You can check the progress of the restore by using the following command:
```
oc get cluster cp4na-o-postgresql
```
When the PostgreSQL cluster is restored successfully, a pod instance is running that corresponds to the cluster instance name. The status of the cluster is Cluster in healthy state. The following sample output shows a restored cluster.
```
NAME               AGE  INSTANCES  READY  STATUS                    PRIMARY 
cp4na-o-postgresql 19h  3          3      Cluster in healthy state  cp4na-o-postgresql-1
```
If the restore process fails, you can use the following commands to find more details:
```
oc get pod | grep postgres
oc logs <pod_name>
```
Run the following command to verify the restored cluster:
```
oc describe cluster cp4na-o-postgresql
```
If no errors are displayed, the cluster is successfully restored. If errors are displayed, you can use commands similar to the following command to review the log of each pod:
```
oc logs cp4na-o-postgresql-1
```
To verify that PVCs are created and check the status of each PVC, run the following commands:
```
oc get pvc cp4na-o-postgresql-1
oc get pvc cp4na-o-postgresql-2
oc get pvc cp4na-o-postgresql-3
```
Restart the ibm-tnc-orchestration-controller-manager pod by running the following commands:
```
oc get deploy
oc edit deploy ibm-tnc-orchestration-controller-manager
```
Change the value of the replicas property to 1, as shown in the following sample YAML:
```
spec:
    progressDeadlineSeconds: 600
    replicas: 1
```
Save the deployment, then wait for the ibm-tnc-orchestration-controller-manager to restart and go into running state.