Restoring an API Connect configuration

As part of your disaster recovery plan, you can restore your API Connect configuration from a file that is stored on an FTP server by using the command-line interface (CLI). Restoring an API Connect configuration involves creating a new on-premises cloud.

1. For each Management server in your on-premises cloud, log in to the CLI through a Secure Shell (SSH), and clear their system states by running the system clean apiconfig command.
   Running this command deletes data and configurations from the Management server, so must be run with caution. However, it is a necessary step so that the other Management servers in the cloud do not conflict with the newly restored system by trying to contact it. If system clean apiconfig doesn't reboot the Management server, then run the system reboot command, so that memory and temporary disk space is cleared in readiness for the restoration.

   For information on logging in to, and using the CLI, see The Command Line Interface.

2. Log in to one of the Management servers through a Secure Shell (SSH).

   This Management server is the first Management server in a new on-premises cloud. Following the restore, this Management server is populated with the details from the backup configuration file, including the organizations, policies, and Products.

3. Restore an API Connect configuration file by using one of the following options:
   • Restore mode from a file that is stored on an FTP server (you can use either FTP or SFTP).

     For FTP, enter the following command:

     

     config load apiconfig ftp  <host> [port <portnumber>] [user <username>] [file <filename>]

     

     config load apiconfig restore ftp  <host> [port <portnumber>] [user <username>] [file <filename>]

     For SFTP, enter the following command:

     

     config load apiconfig sftp  <host> [port <portnumber>] user <username> [file <filename>]

     

     config load apiconfig restore sftp  <host> [port <portnumber>] user <username> [file <filename>]

     Where

     • restore - means that the API management configuration file is loaded as is. (Note that restore mode is selected by default if no option is given.)
     • host - is the name of the host where FTP is running and where the backup configuration file is stored.
     • port - is the port number you are accessing.
     • user - is the user name that is used to log in to FTP.
     • file - is the absolute path or relative path to the stored file on the FTP server.

     Restriction: When you use SFTP, you must specify a user name. Anonymous logins are not allowed with SFTP.
   • By using a local configuration backup file that was created by the automatic configuration backup process.
     Enter the following command:

     config load apiconfig local file <filename>

     Where filename must be a file that was created by the automatic configuration backup process. To see the names of the available configuration backup files, use the config autobackup list command.
   • Isolation mode from a file that is stored on an FTP server (you can use either FTP or SFTP).
     For FTP, enter the following command:

     config load apiconfig isolate ftp  <host> [port <portnumber>] [user <username>] [file <filename>]

     For SFTP, enter the following command:

     config load apiconfig isolate sftp  <host> [port <portnumber>] user <username> [file <filename>]

     Where

     • isolate - means that the management configuration file is loaded without references to DataPower Gateway servers, Developer Portal servers, or any third-party systems for analytics offload.
     • host - is the name of the host where FTP is running and where the backup configuration file is stored.
     • port - is the port number you are accessing.
     • user - is the user name that is used to log in to FTP.
     • file - is the absolute path or relative path to the stored file on the FTP server.

     Restriction: When you use SFTP, you must specify a user name. Anonymous logins are not allowed with SFTP.
     Note: When you restore your configuration in isolation mode, or for testing an upgrade if the new management server cannot reach the original portal server(s), and you want the Developer Portal in the restored configuration to be able to work with the existing catalogs, you must perform the following steps in the newly restored API Manager UI:

     1. For each Catalog, select Settings > Portal, and change the Developer Portal setting to None. Save your changes.
     2. When you want to enable a Developer Portal, for each Catalog you must complete the Settings > Portal section with the new host name for the Developer Portal URL. Save your changes.

   To view the CLI help about the config commands, enter config help.

4. You must wait until the primary Management server is restored and active before you can add other Management servers to the cluster by using the cloud console.
   Note: It can take several minutes for a virtual machine to initialize following the restore of a backup.

   Important: If you want to reuse any Management servers in the new on-premises cloud, you must first delete the existing API Connect configuration. From the CLI, for each of the Management servers, enter system clean apiconfig. Alternatively, you can deploy new virtual Management servers to add to your cloud.

   When the other Management servers are active and defined in the on-premises cloud, the primary Management server automatically synchronizes the API Connect configuration across all of the Management servers in the cluster.

5. For Gateway servers only, if you changed the user ID or password, you must update these credentials in the API Connect cloud console.
   Important: The restored configuration backup includes the Gateway server credentials that were defined in the cloud when the backup file was created. If you do not update the cloud console to change these credentials, the cloud console cannot communicate with the newly restored Gateway servers.