Restoring the management database with a backup CR

Create a ManagementRestore CR that references the Backup CR of the backup you want to restore.

About this task

Management database backups can be restored in the same environment where they were taken, or in a different environment that has the same network configuration, endpoints, and deployment profile. You cannot restore a management database backup in a different network environment, form factor, or deployment profile. If you want to move your API Connect deployment to a different form factor or change endpoints, see Migrating from v10 to v10 on a different form factor.
When you restore a management database backup, you must also restore the database backups of all registered developer portal services, so that the portal and management databases remain in sync.

Note: For OpenShift users: The steps that are detailed in this topic use the Kubernetes kubectl command. On OpenShift, use the equivalent oc command in its place.

Procedure

Identify the existing backup CR that you want to restore:

kubectl -n <management namespace> get backup -o custom-columns="name:.metadata.name,backupId:.status.backupId,endpoint:.status.endpointURL,path:.status.destinationPath,servername:.status.serverName,status:.status.phase"

Example output:

NAME                 BACKUPID          ENDPOINT                            PATH                       SERVERNAME                                        STATUS
test-backup-1.17.1   20230831T110022   https://seaweed.default.svc:30333   s3://backups/backup01ibm   apic-mgmt-d54a2194-db-2023-08-31T11:49:10+01:00   completed

The backup name in this example is test-backup-1.17.1. You can restore the management database from any backup where the STATUS is completed.

If you cannot find the backup CR you want, but it is present on your remote SFTP server or object-store, then you can restore with the backup ID: Restoring the management database with a backup ID.

Verify that the backup is present in your remote SFTP server or object-store:
For example, on an AWS S3 store, run:
```
aws s3 ls <path>
```
where <path> is the location on your object-store store you configured for your management database backups.
Create a file called mgmtrestore_cr.yaml, and paste in the following text:
```
apiVersion: management.apiconnect.ibm.com/v1beta1
kind: ManagementRestore
metadata:
  generateName: management- # this the prefix for the name of the restore CR that is created
spec:
  backupName: <backup CR name>
  subsystemName: <management CR name>   
```
where
- <backup CR name> is the backup name that you identified in step 1.
- <management CR name> is the name of your ManagementCluster CR, run kubectl get mgmt to see what this name is.
Note: If the management database encryption key was changed since the backup was taken (because you followed the steps in Changing the database encryption key), then you must restore the original encryption key before you apply the restore CR. See restore old encryption key.
Start the restore by creating the ManagementRestore CR from the YAML file:
```
kubectl -n <management namespace> create -f mgmtrestore_cr.yaml
```

Verify that the restore is running with:

kubectl -n <management namespace> get ManagementRestore --sort-by=.metadata.creationTimestamp

Example output:

NAME                 STATUS      BACKUP              CLUSTER       MESSAGE                                            PITR                    AGE
mgmt-restore-hr9zx   Complete    mgmt-backup-xnjkl   m1            Restore process completed (DB Restore + DRR job)   9m8s

What to do next

Restore the database backups of any developer portal services that are registered with the management subsystem: Restoring from a portal database backup.