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.

• Configuring scheduled backups
  1. To configure scheduled backups, enter the cassandra-backup-x settings when installing the management subsystem as described in Installing the Management subsystem into a Kubernetes environment. The cassandra-backup-x parameters are also described in the following table:
     The parameters are as follows:

     Parameter	Description
     cassandra-backup-protocol	The backup protocol. Specify one of the following values: sftp - for secure file transfer protocol objstore - for S3 compatible object storage Note: For the management subsystem, IBM Cloud and Amazon Web Services (AWS) are supported S3 object store providers. The public certificate on the S3 storage provider must be signed by a known certificate authority that is trusted by API Connect. Use of an untrusted authority can cause the following error during backup upload: x509: certificate signed by unknown authority.
     cassandra-backup-path	The full path to the directory where the backup files will be stored. This must point to a directory on the backup server. For object storage (objstore) , the path can be set to the bucket value or the bucket/subfolder value.
     cassandra-backup-host	The fully qualified domain name of the backup server. Ensure that the Kubernetes nodes can access this host. If using object store, enter Endpoint/Region. (The "/" character between the endpoint and region are required for this setting.
     cassandra-backup-port	The port for the protocol to connect to the cassandra-backup-host. The backup port is not required for object storage.
     cassandra-backup-schedule	Cron like schedule for performing automatic backups. The format for the schedule is: * * * * * - - - - - | | | | | | | | | +----- day of week (0 - 6) (Sunday=0) | | | +------- month (1 - 12) | | +--------- day of month (1 - 31) | +----------- hour (0 - 23) +------------- min (0 - 59) The backup schedule defaults to 0 0 * * *. This means a backup is run every day at midnight and minute zero. The timezone for backups is UTC. When you configure a host, if you do not specify a value for cassandra-backup-schedule, the default backup schedule is automatically set. Note that the default backup schedule is not set, and scheduled backups not enabled, until host configuration is completed. Note: Cassandra repair cron schedule is set to 00 1 * * 0,2,4,6 . This means the repair runs at 01:00 on Sunday, Tuesday, Thursday, and Saturday. By default, the Cassandra backup cron schedule should not run within one hour of the repair cron schedule. Please make sure to modify the current backup configuration as needed. If backups and repairs run at the same time, backup processes can fail intermittently.
     cassandra-backup-auth-user	The username for the server specified in cassandra-backup-host. If using object store, this would be the S3 Secret Key ID.
     cassandra-backup-auth-pass	The password for the server specified in cassandra-backup-host. If using object store, this would be the S3 Secret Access Key parameter. The password will be stored in Base64 encoded format. For example: apicup subsys set mgmt cassandra-backup-auth-pass '<password>' Note that you cannot use the `=` sign to assign the password to cassandra-backup-auth-pass.

     For example:

     cassandra-backup-protocol: sftp
     cassandra-backup-host: mybackuphost.com
     cassandra-backup-port: 22
     cassandra-backup-path: /backups
     cassandra-backup-schedule: 0 0 * * *
     cassandra-backup-auth-user: myusername
     cassandra-backup-auth-pass: mypassword

  2. These settings will be activated by the apicup subsys install <SUBSYS_NAME> command.
  3. To verify that automatic backups are in progress, you will see a pod labeled <cassandra cluster name>-backup at the scheduled time for the backup.
  4. When the scheduled backup is complete, the backup files are stored at the location specified by the cassandra-backup-path parameter. The file name varies depending upon the API Connect version that performed the backup, but the file name must be compatible with the version used for restoring the database. For details about the file name, see Restoring the management database in a Kubernetes environment.
  5. List the backups by entering: apicup subsys exec <SUBSYS_NAME> list-backups. You can view a list of backups with the ID and Status in the output. Following is an example:

     Cluster               Namespace     ID                   Timestamp                                  Status
     rf0c7310d07-apiconnect-cc   e2edemo       1537987501522014136   2018-09-26 18:45:01.522014136 +0000 UTC   Complete
     rf0c7310d07-apiconnect-cc   e2edemo       1537920006787257385   2018-09-26 00:00:06.787257385 +0000 UTC   Complete

• Performing on-demand backups
  1. Configure the backup parameters. (The same parameters are required for on-demand backup that are required for a scheduled backup, but you will bypass the schedule.) If you did not enter the cassandra-backup-x parameters when you installed API Connect, you will need to enter them from the command line and re-install the management subsystem before performing an on-demand backup.
  2. After the backup parameters have been specified, run the apicup subsys install <SUBSYS_NAME> command to activate the new parameters. This step is not required if you specified these parameters during the initial installation.
  3. Enter the following command: apicup subsys exec <SUBSYS_NAME> backup where SUBSYS_NAME is the name of your management subsystem.
  4. When the back is completed, the backup files are stored at the location specified by the cassandra-backup-path parameter. The file name varies depending upon the API Connect version that performed the backup, but the file name must be compatible with the version used for restoring the database. For details about the file name for the backups, see Restoring the management database in a Kubernetes environment.
  5. List the backups by entering: apicup <subsys exec <SUBSYS_NAME> list-backups. You can view a list of backups with the ID and Status in the output. Following is an example:

     Cluster               Namespace     ID                   Timestamp                                  Status
     rf0c7310d07-apiconnect-cc   e2edemo       1537987501522014136   2018-09-26 18:45:01.522014136 +0000 UTC   Complete
     rf0c7310d07-apiconnect-cc   e2edemo       1537920006787257385   2018-09-26 00:00:06.787257385 +0000 UTC   Complete