You can restore your Management subsystem in your Kubernetes environment.
About this task
To trigger a restore, you will create a ManagementRestore
custom resource. When
the 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.
Procedure
- Obtain a list of the available backups, and decide which one to restore your
Management subsystem:
kubectl get mgmtb -n <your-namespace>
For example:
$ 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 28h
Attention: 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 NAME
column.
- Configure
mgmtrestore_cr.yaml
. Use the copy in the
helper_files
directory 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
management-3aa3bebf
:
backupName: management-3aa3bebf
- Create the
ManagementRestore
CR 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:
- SFTP:
NAME STATUS BACKUP CLUSTER MESSAGE PITR AGE
mgmt-restore-ptx6d Complete mgmt-backup-w4h8c m1 Restore process completed (DB Restore + DRR job) 6m31s
- S3
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