Restoring the analytics database

Deploy the AnalyticsRestore CR to initiate restoration of an analytics database backup.

About this task

Analytics database backups are restored by creating an AnalyticsRestore CR. The API Connect operator detects the presence of the restore CR, and triggers a restore of the backup that is specified in the CR.

Two types of restore are available:

Repair. The repair restore is for recovering corrupted or accidentally deleted indexes. The repair restore compares the contents of your backup and your current analytics database. Any corrupted indexes in your current database are replaced by the corresponding indexes in your backup. Any indexes that are in your backup but are missing from your current database (and are still within your retention period) are restored from the backup.
Note: The current write index is an exception. The current write index is where incoming API events are recorded, and contains the API event data for the current day (if you left your rollover period as the default). If your current write index is corrupted, then open a support case. The repair restore does not recover the current write index.
Replace. The replace restore deletes all indexes in your current database and then restores all the indexes (including the current write index) from the backup that are within your retention period.
A replace restore is used in a disaster recovery situation, where your analytics subsystem is redeployed.

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

Note: Analytics database backups that were taken on an earlier release cannot be restored on V10.0.8.0.

Procedure

Get a list of available backups by running the following command:

kubectl -n namespace get analyticsbackup | grep record

NAME                  STATUS   ID                                     CR TYPE   CLUSTER       AGE   COMMENT
analytics-bup-kxwq5   Ready    analytics-all-2020-09-07t03:49:15utc   record    analytics     34h
analytics-bup-p29z8   Ready    analytics-all-2020-09-07t18:04:03utc   record    analytics     20h

Note the ID of the backup that you want to restore.

Note: You cannot restore backups that have

CR
TYPE

of create.

Create a file called analyticsrestore_cr.yaml and paste in the following text:
```
apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsRestore
metadata:
  generateName: a7s-restore-
spec:
  analyticsCluster: <cluster name>
  backupID: <backup ID>
  type: [repair|replace]
```
- analyticsCluster is the name or your analytics CR. To get the name of your analytics cluster, run:
```
kubectl get AnalyticsCluster
```
- backupID is the ID of the backup that you want to restore, identified in step 1. If you do not specify this property, then the most recent backup is restored.
- type is the type of restore. Set type to repair to recover corrupted or missing indices. Set type to replace to delete all indices and replace with the indices from the backup.
Deploy your CR by running the following command to create it in the namespace of your analytics subsystem:
```
kubectl -n <namespace> create -f analyticsrestore_cr.yaml
```
To monitor your restore, run the following command:
```
kubectl -n <namespace> get analyticsrestore
```
```
NAME              STATUS     ID                                        AGE
a7s-restore-9z4fr Ready      analytics-all-2022-07-01t04:49:15utc               1h
```
When the restore is successfully started, STATUS shows Running. The status that is shown for completed restores depends on your deployment profile:
- On a three replica deployment, STATUS shows Complete.
- On a one replica deployment, STATUS shows Warning. Review step 5 for information on checking restore status.

Display the details for a particular restore by running the following command:

kubectl -n <namespace> get analyticsrestore <restore name> -o yaml

where <restore name> is the name of your restore, that you identified in step 4.

Example output for a one replica deployment where the repair restore is complete:

apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsRestore
metadata:
  creationTimestamp: "2024-06-14T21:42:02Z"
  generateName: analytics-restore-
  generation: 2
  name: analytics-restore-82p6f
  namespace: apic
  ownerReferences:
  - apiVersion: analytics.apiconnect.ibm.com/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: AnalyticsCluster
    name: analytics
    uid: f71b0c9c-1c00-4c1b-b4a4-36643cb92c41
  resourceVersion: "20708170"
  uid: 858796d1-b4b0-42aa-a86e-5060bae9c405
spec:
  analyticsCluster: analytics-2
  backupID: analytics-2-all-2024-06-14t21:14:18.628z
  enableIgnoreUnavailable: false
  enableOverride: false
  type: repair
status:
  backupID: analytics-2-all-2024-06-14t21:14:18.628z
  commentLeft: ""
  conditions:
  - lastTransitionTime: "2024-06-14T21:42:02Z"
    message: ""
    reason: StatusUnknown
    status: "False"
    type: Warning
  - lastTransitionTime: "2024-06-14T21:42:02Z"
    message: SUCCESS
    reason: Finished
    status: "True"
    type: Ready
    ...
  details: summary-api-2024.06.14-000001
  id: "2"
  phase: Ready
  state: ""

The status.details property shows the analytics index that was restored.

When restore is complete, delete the AnalyticsRestore CR:
```
kubectl -n <namespace> delete analyticsrestore <restore name>
```
Note: If your restore failed, and you want to investigate why, do not delete the AnalyticsRestore CR, it is needed for problem analysis.