Backing up Guardium Insights

Use the following procedure to back up Guardium Insights.

Before you begin

If you are backing up to a remote destination, review the requirements for External storage allocation for backups.

Note: As of version 3.2.7, you must provide backup and restore information when you install Guardium Insights, even if you do not plan on backing up and restoring. For more information, see Provide backup and restore information in the Guardium Insights CR (custom resource) file.

Procedure

Verify that you are logged in to the IBM Cloud® Private command-line interface (CLI). Logging in to this CLI also authenticates your account to use the OpenShift® CLI. To log in, run the following command:
```
cloudctl login -a <ICP_hostname> -u <openshift_username> -p <openshift_password> --skip-ssl-validation staging
```
- <ICP_hostname> is your Cloud Private server, for example https://cp-console.apps.myserver.com
- <openshift_username> is your OpenShift username.
- <openshift_password> is your OpenShift password.
Prepare a custom resource file that is named gi-backup.yaml by following the examples in Creating a custom resource file for backups.
Create the backup resource:
```
oc apply -f gi-backup.yaml
```
Confirm that the resource is created:
```
oc get backup
```
The expected results are similar to the following example:
```
NAME       AGE
insights   20m
```
Confirm that the cronjob is created:
1. Run the following command:
```
oc get cronjob|grep backup
```
  The expected results are similar to the following example
```
insights-backup                * */1 * * *   False     0         4m39s           21m
```
2. If the cronjob is not created after 1 minute, restart the operator:
```
oc delete pod $(oc get pod |awk '/guardiuminsights-controller-manager/{print $1;}')
```
  The expected results are similar to the following example
```
pod "guardiuminsights-controller-manager-756b55dff9-zgz5g" deleted
```
3. If needed, remove the backup restore:
```
oc delete backup insights
```
4. And then re-create the backup restore:
```
oc apply -f gi-<timestamp>.yaml
```
5. Restart the operator:
```
oc delete pod $(oc get pod |awk '/guardiuminsights-controller-manager/{print $1;}')
```
  The expected results are similar to the following example
```
pod "guardiuminsights-controller-manager-756b55dff9-zgz5g" deleted
```
6. Check again to see whether the cronjob is created. If it has not, repeat the steps 5.a to 5.e.
At the next scheduled time, a job is created for backup. Check for the job and backup pod until they show up:
To check the job, issue this command:
```
oc get job |grep backup
```
The expected results are similar to the following example
```
insights-backup-1636136400                  0/1           39s        39s
```
To check the pod, issue this command:
```
oc get pod |grep backup
```
The expected results are similar to the following example
```
insights-backup-1636136400-8kj6d            0/1       Pending     0          49s
```
The job and its pod are created, as defined in the gi-backup.yaml file.
Confirm that the status of the pod is Running.
1. Run the following command:
```
oc get pod |grep backup
```
2. If the status shows Pending, similar to this example, the PV is still attached to the PVC:
```
insights-backup-1636136400-8kj6d            0/1       Pending     0          49s
```
3. To determine the status of the PV, run the following command:
```
oc get pv|grep backup
```
  If the PV is attached to the PVC, the expected results are similar to the following example:
```
pvc-7f8c3bb4-5a2c-4408-ad25-fe4f20b604f8   50Gi       RWO            Retain
Released   staging/backup            rook-ceph-block             2d20h
```
4. To manually release the PV, get its name from the results (in this example, it is pvc-7f8c3bb4-5a2c-4408-ad25-fe4f20b604f8), and then run the following command:
```
oc patch pv pvc-7f8c3bb4-5a2c-4408-ad25-fe4f20b604f8 -p '{"spec":{"claimRef": null}}'
```
  The expected results are similar to the following example
```
persistentvolume/pvc-7f8c3bb4-5a2c-4408-ad25-fe4f20b604f8 patched
```
5. To verify that the status of the pod is Running, run the following command:
```
oc get pod |grep backup
```
  The expected results show the Running status:
```
insights-backup-1636136400-8kj6d   1/1       Running           0          6s
```
Watch the pod logs:
```
oc logs --follow insights-backup-1636136400-8kj6d
. . . . .

. . . . .

. . . . .
```
Each run creates a new pod. Wait for the completion of the number of runs that are set in your gi-backup.yaml. The first run produces a full backup, and subsequent runs alternate between delta incremental backups for Db2 and full backups.