Restoring the Analytics database on OpenShift and Cloud Pak for Integration
Deploy the AnalyticsRestore
CR to initiate restoration of a backup of
the IBM® API Connect Analytics
database on OpenShift or Cloud Pak for Integration.
Before you begin
Create a backup. If you intend to restore from a recent backup, ensure that the backup is finished before you start the restore operation.
About this task
A restore operation is triggered by creating the AnalyticsRestore
CR. The new CR
is detected by the ibm-apiconnect
operator, which requests a restore of the
specified backup.
Procedure
-
Find the backup that you want to restore.
-
Get a list of available backups by running the following command:
oc get analyticsbackup -n <APIC_namespace>
where
<APIC_namespace>
is the namespace where the Analytics subsystem is deployed. 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 [all] 34h analytics-bup-p29z8 Ready analytics-all-2020-09-07t18:04:03utc record [all] 20h
Note: You can only restore the Analytics subsystem from backups where theCR TYPE
isrecord
.
-
Get a list of available backups by running the following command:
-
Create the
AnalyticsRestore
CR using either the IBM Cloud Pak Platform UI, the OpenShift web console, or the CLI.In the CR, specify the ID of the backup that you want to restore. For example:
apiVersion: analytics.apiconnect.ibm.com/v1beta1 kind: AnalyticsRestore metadata: generateName: a7s-restore- spec: indices: - all backupID: analytics-all-2022-07-01t03:49:15utc enableIgnoreUnavailable: true enableOverride: false
where:indices
- A list of index names or keywords, indicating which indices you want to restore. Options are:all|apievents|ui
, or the names of individual indices. If no indices are specified, then all indices are restored. The default of 'all' is specified explicitly in the above sample.backupID
- The ID of the backup to be restored. In the example, the backup ID isanalytics-all-2022-07-01t03:49:15utc
.enableIgnoreUnavailable
- Default value isfalse
. If set tofalse
, the restore fails if a specified index is not present in the backup identified by thebackupID
. If set totrue
, missing indices are skipped and the restore continues.enableOverride
- Default value isfalse
. If set totrue
, then the restore overrides existing indices. This might result in a loss of data from the current database.When
enableOverride
is set tofalse
and you specified indices that already exist in the database that you are restoring, then the restore fails. The failure prevents you from accidentally replacing or losing data that exists in the current database.
-
Trigger the restore operation by clicking Create in the UI, or by
running the following command to deploy the CR in the namespace for your Analytics subsystem:
oc create -f analyticsrestore_cr.yaml -n <APIC_namespace>
The restore's name is generated when the restore operation runs.
-
To get a list of restores, run the following command:
oc get analyticsrestore -n <APIC_namespace>
The response looks like the following example.
NAME STATUS ID AGE a7s-restore-01 Running analytics-all-2026-07-01t12:48:49utc 11s
-
Display the details for a particular restore by running the following command:
Use the restore name from the results in the previous step.
oc get analyticsrestore <restore_NAME> -n <APIC_namespace> -o yaml
The result looks like the following example,:
apiVersion: analytics.apiconnect.ibm.com/v1beta1 kind: AnalyticsRestore metadata: generateName: a7s-restore- selfLink: >- /apis/analytics.apiconnect.ibm.com/v1beta1/namespaces/apic/analyticsrestores/a7s-restore-01 resourceVersion: '11267266' name: a7s-restore-01 uid: e772c6c9-754a-45da-a7c7-507a56cbb94a creationTimestamp: '2022-07-01T12:48:50Z' generation: 1 namespace: apic spec: backupID: 'analytics-all-2026-07-01t12:48:49utc' enableIgnoreUnavailable: false enableOverride: true indices: - all status: backupID: '' commentLeft: '' conditions: conditions: - lastTransitionTime: "2022-07-01T14:08:03Z" 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-2022-07-01t14:49:15utc
When the restore is successfully started, the
status: condition
section displaysRunning
. If the restore does not start correctly, thestatus: condition
section displaysFailed
.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 displaysComplete
. Ifstatus: Complete
is not achieved after 3 hours, the status changes toWarning
and the details are no longer updated.Attention: For deployment profiles with fewer than 3 storage nodes, the restore process is never marked asComplete
. 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.