Recovering the Developer Portal subsystem on VMware

Recover the Developer Portal on VMware.

Before you begin

Successful disaster recovery depends on recovery of both the Management subsystem and the Developer Portal subsystem. If you must recover a deployment due to a disaster, you must first complete Recovering the management subsystem on VMware, and then immediately recover the Developer Portal.

Recovery of the Portal subsystem is also dependent on prior completion of the preparation steps: Preparing the Developer Portal subsystem for disaster recovery on VMware

About this task

  • In a disaster recovery scenario, an installation of a new Developer Portal subsystem is required.
  • In a clustered deployment, if any one VM is corrupted then all of the VMs in the cluster must be redeployed. You cannot replace just a single corrupted VM in a cluster.
  • You must use the same project directory that you used for your original Portal deployment, or a restore of your project directory backup, to ensure that configuration and secret information is transferred to the replacement deployment. The apiconnect-up-v10.yaml file contains Portal configuration.

Use the following steps to recover the data from your previous Developer Portal subsystem.


  1. Use your prior existing project directory, or a restore of your project directory backup, to install the replacement Portal subsystem:
    1. Create your ISO files.
      apicup subsys install portal-subsystem-name --out mgmtplan-out

      The --out parameter and value are required.

      In this example, the ISO file is created in the myProject/portal-subsystem-nameplan-out directory.
      Note: If your original ISO files are still available, and you haven't upgraded from the original installation, you can reuse your original files. However, if you have upgraded your original deployment, you must create your ISO files by using the version of apicup that corresponds to the latest release of API Connect that you deployed.
    2. Deploy the files into the replacement VMs. See Deploying the Developer Portal subsystem OVA file.
    3. Verify the deployment. See Verifying deployment of the Developer Portal subsystem.
  2. View the available backups and their status:
    apicup subsys list-backups [subsystem_name] [flags]

    Optional flags:

    ./apicup subsys list-backups -h
    List backups of the subsystem
      apicup subsys list-backups SUBSYS [flags]
      -h, --help               help for list-backups
          --timeout duration   Command timeout in seconds. (default 40s)
    Global Flags:
          --accept-license   Accept the license for API Connect
          --debug            Enable debug logging
  3. Perform a Developer Portal restore.

    Run the following command, and attach any flags as appropriate.

    apicup subsys restore [SUBSYS_NAME] [flags]
    • To restore your Portal service, run the following command:
      apicup subsys restore ptl --timestamp [now|YYYYMMDD.HHMMSS]
      where --timestamp can be now, so the latest backup file that is available is used. Or you can specify a timestamp in the format of YYYYMMDD.HHMMSS to retrieve the nearest backup file to a specified time, searching backwards from the timestamp given. This command executes the portal restore process, which downloads the system backup and all of the site backups from the remote server, and installs them within the Portal stack. This process will then restore the system configuration from the found backup, and restore all of the sites. Note that if a backed up site is already installed on the current stack, then the site is reinstalled by using the backup (the site is overwritten by the backup). If there are multiple sites to restore, then these sites are queued for restoring. You can track the restoration process within the Portal www admin logs.
      Note: From IBM® API Connect Version, the timestamp format changed to YYYYMMDD.HHMMSS. For Version and earlier, the timestamp format is YYYY-MM-DD HH:MM:SS.
    • For a disaster recovery scenario, it is advised that you restore all sites and systems. By default the restore is a complete restore. You can optionally include --type all on the command line to specify a complete restore, but the flag is not required, as a complete restore is performed by default.

      Note that the complete restore uses the priorityList configuration setting that you specified in Configuring backup settings for the Developer Portal subsystem.

    • For more information, see Restoring the Developer Portal subsystem


When the Developer Portal restore CR is marked as Ready, the Disaster recovery is complete for the Developer Portal.