Preparing the Developer Portal for disaster recovery

You can prepare a Developer Portal subsystem for disaster recovery by taking specific steps before and after the installation of the subsystem.

1. Before the initial installation, configure the Developer Portal subsystem for database backups:
   1. Ensure that the Developer Portal backup subsystem secret is created in the cluster.

      This secret contains the credentials (username and password) for the remote storage, such as S3 or IBM Cloud Object Storage, that is used for storing the database backups.

   2. Ensure that the Developer Portal subsystem is configured for database backups.

      Add a databaseBackups subsection to the spec subsection of the Developer Portal subsystem Custom Resource (CR) YAML file. For example:

       portalBackup:
          credentials: portal-backup-secret
          host: s3.eu-gb.cloud-object-storage.appdomain.cloud/eu-standard
          path: test-bucket/restore-test
          port: 443
          protocol: objstore
          schedule: ''

   See also: Backing up and restoring the Developer Portal in a Kubernetes environment
2. After installation, you must back up essential Kubernetes secrets that are used by the Developer Portal subsystem.

   The Kubernetes secrets are created during installation. You must save these secrets in case a restore is needed after a disaster. Then, you use them in the setup of the restored Developer Portal subsystem:

   1. Obtain and save the Developer Portal database encryption secret.

      Use the following command to find the name of the secret in the status of the Developer Portal Subsystem. Replace <namespace> with the namespace used for the subsystem installation:

      kubectl get portal -n <namespace> -o yaml | grep encryption

      The output of this command shows the name of the Kubernetes secret that is storing the database encryption key, for example:

      encryptionSecret: portal-enc-key

      In this case, the name of the Developer Portal database encryption secret is portal-enc-key. Use the following command to back up this secret locally:

      kubectl get secret portal-enc-key -n <namespace> -o yaml > portal_enc_key.yaml

      The secret is stored in a file that is called portal_enc_key.yaml, located in the present working directory.

   2. Obtain the endpoint definitions as they need to stay the same during the restore.
      Get the portalAdminEndpoint name:

      kubectl get portalcluster.portal.apiconnect.ibm.com portal -o jsonpath="{..portalAdminEndpoint.hosts[0].name}"

      Get the portalUIEndpoint name:

      kubectl get portalcluster.portal.apiconnect.ibm.com portal -o jsonpath="{..portalUIEndpoint.hosts[0].name}"

      Note: If you have more than one host specified in the portalUIEndpoint definition, you must get the name for each one.
   3. Ensure that all of these YAML files that contain the various backed-up Secrets are stored persistently and safely.
      Important: If the files are lost, you cannot restore after a disaster event.

      Important: If you update any secrets, remember to take new backups of them.
3. Take note of the value of originalUID in the Portal subsystem CR. You will need it to restore the Portal subsystem. For example:

   
   spec:
     originalUID: "447ea4b3-9514-4a84-a34b-ce0b349838da"

   Note:

   • Version 10.0.3.0 or later: During restore, if you do not specify originalUID, the operator automatically sets its value in the new CR to the value of metadata.uid. If the originalUID in the new CR does not match originalUID in the saved CR, the restore will fail.
   • Version 10.0.2 backups: If planning to restore a Version 10.0.2 backup on Version 10.0.3.0 or later, make a note of the subsystem CR metadata.uid. You must use it when performing a restore on v10.0.3.0 or later, to populate the spec.originalUID value of the CR.
   • Limitation for Version 10.0.2: If planning to restore on Version 10.0.2, performing a restore may not work if the subsystem CR name exceeds 15 characters.
4. If Scheduled backups are set as part of the databaseBackup subsection in the Developer Portal Subsystem CR helper YAML file ( portal_cr.yaml), backups to the specified cloud storage take place.

   You can also complete a manual backup at any time by creating a manual backup CR.

   1. To complete a manual backup, use the Developer Portal backup CR helper YAML file (portalbackup_cr.yaml). For example:

      apiVersion: portal.apiconnect.ibm.com/v1beta1
      kind: PortalBackup
      metadata:
        generateName: portal-bup-
      spec:
        type: all
        crType: create
        comment: "test comment"

      Run the following command to start a manual backup to the configured cloud storage:

      kubectl create -f portalbackup_cr.yaml -n <namespace>

   2. Use the following command to list the backups:

      kubectl get portalbackup -n <namespace>

      For example:

      loginabc@localhost ibm-apiconnect]$ kubectl get pb
      NAME               ID                STATUS   TYPE   CR TYPE   AGE     COMMENT
      portal-bup-g66gv                     Ready    site   create    5m27s   y
      portal-bup-z7wgk   20201001.100021   Ready    site   record    4m24s   

      With stored backups, secrets and siteName saved, the stack is now ready for a restore after a disaster event.