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.

Procedure

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
```

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

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
```
where:
- 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.
```
Successful:7}}

  Id:     analytics-all-2020-09-07t03:49:15utc
  Phase:  Ready
  State:
```

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:

apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsRestore
metadata:
  generateName: a7s-restore-
spec:
  indices: 
  - ui
  backupID: analytics-all-2020-09-07t03:49:15utc
  enableIgnoreUnavailable: true
  enableOverride: false

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

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

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:
```
apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsRestore
metadata:
  creationTimestamp: "2020-10-21T15:06:03Z"
  generateName: a7s-restore-
  generation: 1
  name: a7s-restore-9z4fr
  namespace: my-namespace
  resourceVersion: "975152"
  selfLink: /apis/analytics.apiconnect.ibm.com/v1beta1/namespaces/my-namespace/analyticsrestores/a7s-restore-9z4fr
  uid: fdda9105-17ab-44ac-83de-852620a4dcde
spec:
  backupID: analytics-all-2020-09-07t03:49:15utc
  enableIgnoreUnavailable: false
  enableOverride: true
  indices:
  - ui
status:
  conditions:
  - lastTransitionTime: "2020-10-21T18:07:05Z"
    message: WARNING
    status: Warning
    type: Ready
  details: |
    &{NumberOfDataNodes:1
    Status:yellow
    ActivePrimaryShards:23
    ActiveShards:23
    RelocatingShards:0
    InitializingShards:0
    UnassignedShards:40
    PendingTasks:0}
  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.
Attention:
- 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.