Oracle® Fusion Middleware
Part 3. Manage API Gateway operation

You must ensure that your API Gateway system can recover from any natural disasters (for example, floods, hurricanes, or earthquakes) and human-induced disasters (for example, failures, fires, or explosions).

Many organizations have a mirrored backup and disaster recovery site with full capacity to recover from any major incidents. These systems are typically kept in a separate physical location on cold stand-by until they need to be brought into action. In this case, the backup and disaster site must be a mirrored image of production environment that replicates all resources and assets (for example, LDAP and databases), and with the same number of API Gateway instances. You should ensure that any required third-party systems are included in your backup and recovery solution.

Example approaches to keeping production and backup environments in sync include making backups to disk or tape, and sending these off-site at regular intervals, or cloud-based solutions that replicate on-site systems, and back up to off-site data centers.

Whichever backup strategy you choose, in a production environment you must ensure that API Gateway installations on all API Gateway host nodes are backed up on a regular basis. For example, this includes hosts that run the following components:

You must also back up all databases and third-party systems used with the API Gateway. For example, this includes the following:

	Note
	You do not need to back up Policy Studio, Configuration Studio, or API Gateway Explorer because these tools run in a temporary workspace when required. However, if you have modified any third-party dependencies on the Preferences page (for example, to connect to a specific database), you must also add the relevant .jar on the Runtime Dependencies page in your disaster recovery environment.

To back up an API Gateway installation, you must back up files that have changed in the following directory:

<install-dir>\apigateway

This backs up all Admin Node Manager, Node Manager, , and API Gateway instances in that installation.

For example, the following directories include API Gateway configuration, and will typically need to be backed up on a regular basis:

<install-dir>\apigateway\conf
<install-dir>\apigateway\groups
<install-dir>\apigateway\ext
<install-dir>\apigateway\system\conf\nodemanager.xml

	Note
	Before backing up, you can remove the contents of the apigateway\conf\opsdb.d directory. This contains transient monitoring data, which can be quite large in some cases, and does not need to be backed up.

Similarly, to back up an API Gateway Analytics installation, you must back up files that have changed in the following directory:

<install-dir>\oaganalytics

For example, the following directories include API Gateway Analytics configuration, and will typically need to be backed up on a regular basis:

<install-dir>\oaganalytics\conf
<install-dir>\oaganalytics\ext

	Note
	This backs up the API Gateway Analytics installation only. You must also back up the metrics database separately. For more details, see the next section.

You must back up all databases and third-party systems used with the API Gateway. For example, you can back a MySQL database by creating a dump file of the tables in use:

mysqldump -u root temp_backup > db_tables.dump

For more details, see the user documentation for your third-party system.

To ensure that your backup and disaster recovery processes are successful, you should conduct full restoration tests on a regular basis. You must ensure that you can restore all required files as quickly and easily as possible.

To ensure this, your backup and disaster recovery plan should include key metrics for recovery points and recovery times for your real-world business processes (for example, creating a purchase order, booking a reservation, and so on).

This simple example shows how to create a disaster recovery site from a backup of an API Gateway production deployment. It assumes that both the disaster recovery site and the primary production site have the same version of API Gateway installed. In this scenario, the disaster recovery site is a cold standby, and the configuration from production is replicated using a backup of production configuration.

Back up the production environment

To back up the production environment, perform the following steps.

1. Browse to the directory where the API Gateway is installed (for example, /opt/apigateway or c:\apigateway).

2. Tar or zip the following:

   • apigateway/groups

   • apigateway/conf

   • apigateway/system/conf/nodemanager.xml

   • apigateway/ext

   On Linx and UNIX, if you want the API Gateway and Node Manager to start up automatically on the new host, you should also include /etc/init.d/vshell-*.

	Note
	This includes separate startup scripts files for the Node Manager and API Gateway instances if an init.d script was created using managedomain during initial setup. You can create these at any time using managedomain, and choosing option 2, Edit a host, for a Node Manager, or option 10, Add script or service for an existing local API Gateway. For more details, see Managedomain command reference.

For example, the following command creates a .tar file running from the root directory:

>tar -cvf apigateway_backup.tar /opt/apigateway/conf /opt/apigateway/groups    
  /opt/apigateway/system/conf/nodemanager.xml 

The following example creates a .tar file containing the startup scripts running from the root directory:

> tar -cvf startup_scripts.tar /etc/init.d/vshell-*

Copy to the disaster recovery site

To replicate to the disaster recovery site:

1. Copy the created .tar file(s) from the primary production machine to the cold standby machine.

   	Note
   	Ensure the files are tarred before copying because this preserves the permissions and ownership of the files.

2. Untar or unzip the files so that they are extracted in the same directories, overwriting existing files if necessary.

   The following example untars the files from the root directory:

   >tar -C / -xvf apigateway_backup.tar

   The following is optional:

   >tar -C / -xvf startup_scripts.tar

3. When all the files are copied over and extracted successfully, you should be able to start the Admin Node Manager and API Gateway instances the same way as in primary production site running the same topology and configurations.

	Note
	This example assumes that backups are collected on regular basis from the master node in the production site.

For details on how to back up and restore an Admin Node Manager for signing SSL certificates in a API Gateway domain, see the section called “Admin Node Manager backup and disaster recovery”.