Management subsystem disaster recovery

Recover the management subsystem in a VMware environment.

About this task

Recovering the management subsystem involves re-creating your management ISO files, redeploying your management VMs with the new ISO files, and then restoring the management database from your backup.

Important points:
  • In a three replica deployment, if any one VM is corrupted then all the VMs in the cluster must be redeployed. You cannot replace just a single corrupted VM in a cluster.
  • When you restore the management subsystem database, you must then restore the portal subsystem database from a backup that was taken at the same time. The database backups of the management and portal must be taken at the same time to ensure that the portal sites are consistent with management database.
  • The disaster recovery process is intended for restoration of API Connect in the same VMware environment with the same endpoints.

    If you want to restore in a different VMware environment, all configured API Connect endpoints must be valid in the new environment. If the original host name or IP address was not used in any of your API Connect endpoints, then you can give your VMs a different hostname and IP address.

    If you want to change API Connect endpoints or migrate to a different form-factor, see Migrating from v10 to v10 on a different form factor.

Procedure

  1. Use the same project directory that you used for your original deployment, or a restore of your Project directory backup.
  2. Create your ISO files:
    apicup subsys install <subsystem name> --out <output directory>
    where <output directory> is the directory where the ISO files are to be created.
    Note: If your original ISO files are still available and you did not upgrade from the original installation, you can reuse them. However, if you upgraded your original deployment, you must create new ISO files using the version of apicup that corresponds to the version your API Connect installation was on at the time of the disaster. For example, do not attempt to deploy v10.0.8.x OVAs with ISO files that were created with apicup v10.0.6.0.

    If you are restoring in a different VMware environment, you can change the hostname, IP address, and other properties that you set with apicup iface create before you create the ISO files. Use apicup iface create to define your new network interface, and then apicup iface delete to delete the original one. Do not update any other settings with apicup, and if your original VM hostname was used in any of your API Connect endpoints, then you cannot change the hostname.

  3. Deploy your new management VMs: Deploying the management subsystem OVA.
  4. Restore the management subsystem certificates with the apicup commands that you generated in Backing up your management certificates.
    Run the apicup from the apicup-commands.txt file:
    apicup certs set management atm-credential --encoded-string '<encoded_string>'
    apicup certs set management consumer-toolkit-credential --encoded-string '<encoded_string>'
    apicup certs set management designer-credential --encoded-string '<encoded_string>'
    apicup certs set management toolkit-credential --encoded-string '<encoded_string>'
    apicup certs set management juhu-credential --encoded-string '<encoded_string>'
    apicup certs set management consumer-ui-credential --encoded-string '<encoded_string>'
    apicup certs set management ui-credential --encoded-string '<encoded_string>'
    apicup certs set management encryption-secret --encoded-string '<encoded_string>'
    apicup certs set management discovery-credential --encoded-string '<encoded_string>'
    apicup certs set management governance-credential --encoded-string '<encoded_string>'
    apicup subsys set management site-name='<site_name>'
  5. Verify your new management deployment, but do not log in to the Cloud Manager UI or attempt to configure or change any other settings: Verifying the management subsystem installation.
  6. Restore your management database backup, using backup ID.