Backing up the management database in a Kubernetes environment
Backups of the management database can be performed based upon a cron-like schedule or on-demand from the command line.
About this task
Database backups can be used to restore the database for disaster recovery or for transferring data during an upgrade.
- For scheduled backups, see Configuring scheduled backups
- For on-demand backups, see Performing on-demand backups
We strongly recommend that you configure a backup schedule for your management database using the
cassandra-backup-schedule
setting during installation of the management subsystem.
If you did not do so when you installed API Connect in your
Kubernetes runtime environment, you have the option to perform an on-demand backup. We also
recommend that you perform a backup (either scheduled or on-demand) of the management database prior
to upgrading.
Both scheduled backups and on-demand backups require that the cassandra-backup-x settings be configured when installing the management subsystem. Automatic scheduled backups are performed according to the cron-like job configured by the cassandra-backup-schedule setting. On-demand backups also require the backup settings for protocol, host, etc., but are run on-demand from the command line.
- You must back up both the Management and Portal subsystems at the same time, to ensure synchronicity across the services.
- The original project directory created with APICUP during the initial product installation (for example, myProject) is required to both restore the database and to upgrade your deployment. You cannot restore the database or perform an upgrade without the initial project directory because it contains pertinent information about the cluster. A good practice is to back up the original project directory to a location from where it can always be retrieved.