Backing up the management subsystem in VMware environments

Backups of the management database can be performed based upon a cron-like schedule or on-demand from the command line.

Before you begin

The backup and restore feature is enhanced for API Connect Version 2018.4.1.

.

About this task

Database backups can be used to restore the database for disaster recovery or for transferring data during an upgrade.

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 VMware 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.

There are two options for performing backups of the management database: scheduled backups and on-demand backups. Both options require the cassandra-backup-x settings to 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, but are run on-demand from the command line.

Note: You must back up both the Management and Portal subsystems at the same time, to ensure synchronicity across the services.

Procedure

  • Configuring scheduled backups
    1. To configure scheduled backups, enter the cassandra-backup-x settings when installing the management subsystem as described in Deploying the Management subsystem in a VMware 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 back 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 a management subsystem in a VMware 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
  • 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 backup 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 a management subsystem in a VMware 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

Results

Use the ID generated for the backup files to restore the database from the backup. Usually the database is restored from a backup file after an upgrade is performed and to recover from a disaster. See Restoring a management subsystem in a VMware environment and Upgrading API Connect subsystems in a VMware environment.