Backing up and restoring

You can backup and restore API Connect subsystems.

API Connect Version 10 uses Kubernetes operators to back up and restore databases.

• Backups are for recovery of the API Connect subsystems in the same environment that the backups were taken. 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.
• Manual backups

  For the management database, the backup configuration is specified in a Management CR (custom resource). You create the backup CR manually. Once the backup CR is created, the apiconnect operator performs backup and updates the status into the backup CR.

• Scheduled backups

  For scheduled backups, you can add a backup schedule to the backup configuration details in the management CR. The apiconnect operator will then trigger and perform backups as specified in the custom cron schedule. A backup CR is created for every individual backup invocation as described in the cron schedule. You can view each backup CR to determine the status of each backup.

• Restore

  For restore, you update the backup Management CR. You then create a restore CR with the backup name in it. You can list the backup CRs and determine the backup name by looking at individual backup CR. The apiconnect operator performs the restore.

• You must backup both the Management and Portal subsystems at the same time, to ensure synchronicity across the services.
• If you have to perform a restore, you must complete the restoration of the Management Service first, and then immediately restore the Developer Portal. The backups of the Management and Portal must be taken at the same time to ensure that the Portal sites are consistent with Management database.
• When restoring, the Management, Analytics, and Developer Portal subsystems must be at the same version and fix pack level.