Restoring the Analytics database

Deploy the analyticsrestore_cr.yaml CR to initiate restoration of a backup of the IBM® API Connect Analytics database on VMware.

Before you begin

Create a backup.

About this task

A restore operation is triggered by creating the analyticsrestore_cr.yaml CR. The new CR is detected by the ibm-apiconnect operator, which requests a restore of the specified backup.

Note: You can only run one backup or restore process at a time.


  1. Connect to the management subsystem using SSH:
    1. Run the following command to connect as the API Connect administrator.
      ssh ip_address -l apicadm
    2. When prompted, select Yes to continue connecting.
    3. Get the necessary credentials:
      sudo -i
  2. Get a list of available backups by running the following command:
    kubectl get analyticsbackup -n namespace

    where namespace is the name of the Analytics namespace.

    The response looks like the following example. Note down the ID of the backup that you want to restore.

    NAME                  STATUS   ID                                     CR TYPE   INDICES                 AGE   COMMENT
    a7s-bup-266p8         Ready                                           create    [all]                   20h   y
    a7s-bup-pffdh         Ready                                           create    [all]                   34h   y
    analytics-bup-kxwq5   Ready    analytics-all-2020-09-07t03:49:15utc   record    [ui apievents config]   34h
    analytics-bup-p29z8   Ready    analytics-all-2020-09-07t18:04:03utc   record    [ui apievents config]   20h
  3. Get the ID of the backup that you want to restore:
    Note: You can only restore the Analytics subsystem from backups where the CR TYPE is record.
    kubectl describe a7b analytics-bup-kxwq5 -n namespace
    • analytics-bup-kxwq5 is the NAME of a backup of CR type record
    • namespace is the name of the Analytics namespace

    The response looks like the following example. Note down the ID.

      Id:     analytics-all-2020-09-07t03:49:15utc
      Phase:  Ready
  4. Create the AnalyticsRestore CR for your deployment in a file called analyticsrestore_cr.yaml.

    The following code shows the sample analyticsrestore_cr.yaml, which is stored in the helper_files directory:

    kind: AnalyticsRestore
      generateName: a7s-restore-
      - ui
      backupID: analytics-all-2020-09-07t03:49:15utc
      enableIgnoreUnavailable: true
      enableOverride: false
  5. In your copy of the CR, update the following settings:
    • indices - A list of index names or keywords, indicating which indices you want to back up. If no indices are specified, then all indices are backed up. The following supported keywords are mapped to indices or aliases in Elasticsearch:
      • all - Restore all data. This is equivalent to listing all of the remaining keywords (apievents, ui, config).
      • apievents - Restore all analytics data.
      • ui - Restore all UI visualizations and dashboards.
      • config - Restore all configuration information, such as the retention period.
    • backupID - The ID of the backup to be restored, which you obtained in step 3.
    • enableIgnoreUnavailable - Default value is false. If set to false, the restore fails if a specified index is not present in the backup identified by the backupID. If set to true, missing indices are skipped and the restore continues.
    • enableOverride - Default value is false. If set to true, then the restore overrides existing indices.
  6. Deploy your CR by running the following command to create it in the namespace for your Analytics subsystem:
    kubectl create -f analyticsrestore_cr.yaml -n Namespace_of_Analytics_Subsystem

    The restore name is generated when the restore operation runs.

  7. To get a list of restores, run the following command:
    kubectl get analyticsrestore -n namespace

    The response looks like the following example.

    NAME              STATUS     ID                                        AGE
    a7s-restore-9z4fr Warning    analytics-all-2020-09-07t03:49:15utc                             47h
  8. Display the details for a particular restore by running the following command:

    Use the restore name from the results in step 6.

    kubectl get analyticsrestore restore_NAME -n namespace -o yaml

    The result looks like the following example:

    kind: AnalyticsRestore
      creationTimestamp: "2020-10-21T15:06:03Z"
      generateName: a7s-restore-
      generation: 1
      name: a7s-restore-9z4fr
      namespace: my-namespace
      resourceVersion: "975152"
      selfLink: /apis/
      uid: fdda9105-17ab-44ac-83de-852620a4dcde
      backupID: analytics-all-2020-09-07t03:49:15utc
      enableIgnoreUnavailable: false
      enableOverride: true
      - ui
      - lastTransitionTime: "2020-10-21T18:07:05Z"
        message: WARNING
        status: Warning
        type: Ready
      details: |
      id: analytics-all-2020-09-07t18:04:03utc

    When the restore is successfully started, the status: condition section displays Running. If the restore does not start correctly, the status: condition section displays Failed.

    The restore process is successful when the storage cluster status is green, there are no unassigned shards, and there are no initializing shards. At that time the status: condition section displays Complete. If status: Complete is not achieved after 3 hours, the status changes to Warning and the details are no longer updated.

    • For deployment profiles with fewer than 3 storage nodes, the restore process is never marked as Complete. The storage cluster status is expected to be yellow and to have more than 0 unassigned shards. In this situation, the restore process is likely to be complete when there are 0 initializing shards.
    • When you restore v2018 data after upgrading the development profile, there will be a short delay before the restored data displays in the Analytics user interfaces.