Backing up, restoring, and disaster recovery

Backup your API Connect subsystems, configure scheduled database backups, and recover from a disaster.

Backups for the management, portal, and analytics subsystems consist of an infrastructure configuration backup and a database backup.
Note: The gateway receives all its configuration from the management subsystem, and does not require a backup.
Infrastructure configuration backup
Your infrastructure configuration backup includes everything that you configure for API Connect in your deployment environment, such as:
  • Subsystem YAML files (or top-level CR YAML file).
  • Custom certificates. Such as certificates used to secure communication with remote systems like analytics offload targets.
  • Encryption secrets.
  • Backup secrets.

The infrastructure configuration backup is also referred to as the config backup.

If you have a disaster, your config backup is essential for restoring your API Connect subsystems.

Config backups must be taken manually, by exporting your API Connect Kubernetes artifacts to YAML files. If you make a configuration change, you must update your config backup.

Subsystem database backups

Your subsystem database backups contain everything that API Connect users configure in the API Connect UIs, the toolkit CLI, and the REST API. Subsystem database backups for portal contain all site customizations. The analytics database backup contains all your analytics data.

Subsystem database backups can be configured to run automatically, and can also be taken on-demand.

Important points:
  • Subsystem database backups are for recovery in the same environment that the backups were taken, or in a different environment that has the same network configuration and form factor. If you want to move your API Connect deployment to a different environment and change the form factor, or modify your API Connect endpoints, then see Migrating from v10 to v10 on a different form factor.
  • The management and portal subsystems databases must be kept in sync with each other, so take management and portal database backups at the same time. When you perform a management or portal database restore, complete the restoration of the management database first, and then restore the developer portal.

Two data center disaster recovery deployments

Two data center disaster recovery deployments have additional backup, restore, and disaster recovery considerations. Review the Backup and restore requirements for a 2DCDR deployment before you follow the topics in this section.