Restoring the management subsystem (v10.0.1.1 or later)
You can restore your Management subsystem in your Kubernetes environment.
You must have backups of the management subsystem in order to restore. See Configuring backup settings for fresh install of the Management subsystem and Generating a manual backup of the management subsystem.
Before you begin
About this task
To trigger a restore, you will create a
ManagementRestore custom resource. When
ibm-apiconnect operator detects the new CR, it starts the restore process.
- Ensure that the backup method that you used is complete before you attempt a restore. The backup data that is stored in the remote server is used for restoring the Management subsystem data back to a previous state. Ensure that these backups are on your remote server before you attempt a restore, and that the backup ID in the selected backup exists in remote storage.
- Restoring a backup restores the registration credentials (client_ID, client_secret) that were in use at the time that the selected backup was created. For information on the registration credentials, see Changing the registration client_id and client_secret for applications.
- If you have to perform a restore, you must complete the restoration of the Management Service first, and then immediately restore the Developer Portal. The backups of the Management and Portal must be taken at the same time to ensure that the Portal sites are consistent with Management database.
Note: There is a known issue where sometimes a restore from the Management subsystem's SFTP backup succeeds but the data is not restored. If this happens, run the restore again.
- Obtain a list of the available backups, and decide which one to restore your
kubectl get mgmtb -n <your-namespace>
$ kubectl get mgmtb NAME STATUS ID CLUSTER TYPE CR TYPE AGE management-3aa3bebf Ready 20200929-152150F management full record 10h management-3c4ca8df Ready 20200929-115520F management full record 20h management-5tbxj Ready 20200929-224349F management full create 17h management-f10af337 Ready 20200925-133703F management full record 5d2h management-jtlcd Ready 20200929-224349F management full create 25h management-zxjtz Ready 20200929-224349F management full create 28hAttention: You can restore the Management subsystem from any backup where the STATUS is Ready; however, you should avoid restoring to the initial system backup. During installation, the Management database is used for an initial system backup before certain database schema jobs are complete. Restoring to this backup will result in an unstable system.
You will use one of the values in the
mgmtrestore_cr.yaml. Use the copy in the
helper_filesdirectory as an example:
apiVersion: management.apiconnect.ibm.com/v1beta1 kind: ManagementRestore metadata: generateName: management- spec: backupName: management-3aa3bebf
backupName: is the name of the backup custom resource you want to restore to. Note that the sample uses example output from the previous step, to specify the backup named
- Create the
ManagementRestoreCR in the namespace of the Management Subsystem to trigger the restore process:
$ kubectl create -f mgmtrestore_cr.yaml -n <namespace-of-mgmt-susbystem>
- You can list current restores using the following command:
$ kubectl get managementrestore -n <namespace-of-mgmt-subsystem> --sort-by=.metadata.creationTimestamp
Here is an example of some possible output:
NAME STATUS BACKUP CLUSTER MESSAGE PITR AGE mgmt-restore-ptx6d Complete mgmt-backup-w4h8c m1 Restore process completed (DB Restore + DRR job) 6m31s
NAME STATUS BACKUP CLUSTER MESSAGE PITR AGE mgmt-restore-hr9zx Complete mgmt-backup-xnjkl m1 Restore process completed (DB Restore + DRR job) 2020-11-23 23:08:32+00 9m8s