Backing up an IBM API Connect cloud

You can back up your IBM® API Connect on-premises cloud by using the tools that are provided by your virtualization environment.

About this task

To preserve your data, in case of disaster recovery, you must back up each of the Management appliances that you have defined in your development, test, or production environments. These appliances are defined in the cloud console as Management servers.

The Management servers contain important API Connect details. The details include the record of your organization accounts, the APIs, details of the Products, and the applications that your developers registered that call your APIs.

Note: Take snapshots of all of the servers within a cluster in quick succession to ensure that the backups of each appliance contain a consistent view of the state of the cloud. For example, take snapshots of all of the Management appliances at the same time. Note that snapshots are not the same as backups. A snapshot is a change log of the original virtual disk, and is not portable. Therefore, do not rely on it as your only backup process. The virtual machine runs on the most current snapshot, not the original vmdk disk files. For optimum recovery readiness, you should take both snapshots and backups of your configuration.
For VMware, you can take one of the following approaches:
  • For short-term scenarios such as taking a checkpoint immediately before you apply a fix pack upgrade, you can choose to take a VMware snapshot of the instances. You can then delete the snapshot after a few days after you confirm that the changes were successful.
  • For long-term backup and restore, consult your VMware administrator about your organizations approach to VMware instance backup.
    Important: Only the following backup mechanisms are supported:

    Virtual machine cloning and third-party solutions are not supported.

Procedure

There are two approaches that you can take when backing up your IBM API Connect cloud: offline backup, and online backup.

  • To carry out an offline backup, complete the following steps.
    1. Turn off all Management servers.
    2. Take a snapshot of all Management servers, Developer Portal servers, and, if possible, all Gateway servers.
    3. Turn on all servers.
  • To carry out an online backup, complete the following steps, ensuring that you capture the primary server last so that its data is completely up to date.
    1. Determine which Management server is the primary server by opening the Cloud Manager and, in the Clusters page, clicking the Server details icon for each server in the Management cluster. The primary server has the role PRIMARY, and the secondary servers have the role RSS.
    2. If possible, take a snapshot of all virtual Gateway servers.
    3. Take a snapshot of all secondary Management servers.
    4. Take a snapshot of the primary Management server.
    5. Take a snapshot of all Developer Portal servers.
      To avoid the risk of database reclustering issues on restoration, when you take a snapshot of a Developer Portal cluster, the database of each server should be stopped before the snapshot is taken, and then restarted again after. In this way, you can achieve a rolling snapshot of your cluster with zero downtime. If you must restore all the snapshots at the same time, then the cluster will automatically bootstrap itself with the data from the last server that was snapshot. For more information about taking snapshots of Developer Portal servers, see Backing up and restoring the Developer Portal.

What to do next

Schedule regular backups of your Management servers.