Disaster recovery on OpenShift top-level CR

About this task

To recover your API Connect deployment, follow the steps in this topic along with the instructions for Installing with the top-level CR on OpenShift.

Note: The steps that are detailed in this topic use the Kubernetes kubectl command, which does work on OpenShift®, but if you want you can replace kubectl with the OpenShift equivalent command: oc.

Procedure

Create the management subsystem Kubernetes secrets from the backup YAML files that you created in Management infrastructure configuration backup.
1. Create the database encryption secret with the management_enc_key_backup.yaml file:
```
kubectl -n <management namespace> apply -f management_enc_key_backup.yaml
```
2. Create the backup credential secret with your mgmt-backup-secret_backup.yaml file:
```
kubectl -n <management namespace> apply -f mgmt-backup-secret_backup.yaml
```
3. Create the credential secrets with the <credential secret>_backup.yaml files you saved in step 5 of Taking a management infrastructure configuration backup:
```
kubectl -n <management namespace> apply -f <credential secret backup file>
```
4. Set the object-store CA secret (if required) from your backup file:
```
kubectl -n <management namespace> apply -f mgmt_custom_objstore_ca.yaml
```
5. Create the secrets for any customized certificates from their backup files:
```
kubectl -n <management namespace> apply -f <custom certificate secret backup file>
```
Create the portal subsystem Kubernetes secrets from the backup YAML files that you created in Portal infrastructure configuration backup.
1. Create the database encryption secret with the portal_enc_key_backup.yaml:
```
kubectl -n <portal namespace> apply -f portal_enc_key_backup.yaml
```
2. Create the backup credential secrets with your ptl-backup-secret_backup.yaml file:
```
kubectl -n <portal namespace> apply -f ptl-backup-secret_backup.yaml
```
3. Create the S3 CA secret (if required) with:
```
kubectl -n <portal namespace> apply -f portal_custom_s3_ca.yaml
```
4. Create the secrets for any customized certificates from their backup files:
```
kubectl -n <portal namespace> apply -f <custom certificate secret backup file>
```
Re-create the analytics secrets that you backed up. See Backup analytics secrets.
To prepare for disaster recovery when using a top-level API Connect cluster CR, follow these steps:
1. Copy and paste the spec section from your apic_cr_backup.yaml file.
2. Set the following required fields under spec.management and spec.portal:
  
  siteName:
  
  Copy the value from the original subsystem CR.
  
  originalUID:
  
  Copy the value from the spec.originalUID field or the metadata.uid field in the original subsystem CR.
  
  encryptionSecret:
  
  Use the name of the encryption secret that you created in step 1.a and 2.a.
  
  customApplicationCredentials:
  
  Include all secret references that were used during the original installation. This field applies only to the Management subsystem.
  
  Note: If your cluster name is longer than 10 characters, and the siteName and originalUID fields are missing, the restore operation will fail due to secret mismatches.
  Example:
```
spec:
  management:
    siteName: "a2a5e6e2"
    originalUID: "fa0f6f49-b931-4472-b84d-0922a9a92dfd"
    encryptionSecret:
      secretName: mgmt-enc-key
    customApplicationCredentials:
    - name: atm-cred
      secretName: management-atm-cred
    ...
  portal:
    siteName: "890772e3"
    originalUID: "447ea4b3-9514-4a84-a34b-ce0b349838da"
    encryptionSecret:
      secretName: portal-enc-key
```
Create the API Connect deployment from the YAML file.
Refer to the installation steps in Installing with the top-level CR on OpenShift.
Wait for all subsystems to be created and ready. Monitor the installation progress with the command:
```
oc -n <namespace> get ApiconnectCluster
```
Restore the subsystem databases:
1. Restoring the management database with a backup ID.
  Verify that the restoration completed successfully and that the management subsystem is Ready, then proceed to the next step and restore the portal subsystem.
2. Restoring from a portal database backup.
  Use the restore type all to ensure that you restore the complete subsystem and all portal sites.
3. Restoring the analytics database.