Back up and restore MongoDB during conversion to a multiple-namespaces installation
Important: This content is a technical preview, and should not be relied on in a production environment.
Before you convert your single-instance cluster to a multiple-instances cluster, you can back up MongoDB. You can restore it after the conversion is complete.
Note: If you are running the script in an air-gapped environment, you must download the scripts to the environment first. The following are the locations of the scripts that you must download:
- backup_restore_mongo.sh
- mongo-backup.sh
- mongodbbackup.yaml
- mongo-restore.sh
- mongodbrestore.yaml
- set_access.js
Prerequisites
You need a storage class with reclaim policy as retain
for MongoDB before you can run the backup job.
To create the storage class, complete these steps:
-
Log in to your cluster by using the
oc login
command. -
Get the persistent volume (PV) name to which MongoDB is bound.
oc get pv -n <namespace-where-foundational services-are-installed> | grep mongodbdir
-
Find the storage class of the PV.
oc edit pv <pv-name-from-previous-command>
Note the storage class name from the
storageClassName
parameter. -
Copy the storage class definition to a YAML file.
oc get sc <storage-class-name-from-previous-command> -o yaml > sc.yaml
-
Update the
metadata.name
tobackup-sc
and thereclaimPolicy
toRetain
.vi sc.yaml
-
Create the storage class.
oc apply -f sc.yaml
Back up MongoDB
Create a role-based access control (RBAC) job for MongoDB, and run the backup script.
-
Define the job with the following content in a file named
cs-job-rbac.yaml
.kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: cs-br subjects: - kind: ServiceAccount name: default namespace: <namespace-where-foundational services-are-installed> roleRef: kind: ClusterRole name: cluster-admin apiGroup: rbac.authorization.k8s.io
-
Create the job.
oc apply -f cs-job-rbac.yaml
-
Create an environment variable with the namespace where foundational services are installed.
export CS_NAMESPACE=<namespace-where-foundational services-are-installed>
-
Get the MongoDB backup job.
wget https://raw.githubusercontent.com/IBM/ibm-common-service-operator/scripts/velero/backup/mongoDB/mongodbrestore.yaml
-
Get the MongoDB backup script.
wget https://raw.githubusercontent.com/IBM/ibm-common-service-operator/scripts/velero/backup/mongoDB/mongo-backup.sh
-
Edit the MongoDB backup script file and replace the
spec.storageClassName
parameter value with the storage class that you created in the prerequisites section.vi mongo-backup.sh
-
Run the MongoDB backup script.
./mongo-backup.sh
-
Verify whether a persistent volume claim (PVC) named
cs-mongodump
is created in your foundational services namespace. Note the volume name from the command output.oc get pvc -n $CS_NAMESPACE | grep cs-mongodump
-
Verify whether the PV to which the PVC is bound has
persistentVolumeReclaimPolicy
asRetain
.oc edit pv <volume_name_from_previous_step> -n $CS_NAMESPACE
Next, continue with converting your cluster to a multiple-instances cluster. See Converting a single-namespace installation to a multiple-namespaces installation.
Restore MongoDB
Restore MongoDB in your converted cluster.
-
Copy the
cs-mongodump
PVC contents to a YAML file. Note the volume name from the command output.oc edit pvc cs-mongodump -n $CS_NAMESPACE >> cs-mongodump-copy.yaml
-
Delete the
cs-mongodump
PVC.oc delete pvc cs-mongodump -n $CS_NAMESPACE
-
Delete the MongoDB backup job.
oc delete job mongodb-backup-job -n $CS_NAMESPACE
-
Edit the PV of the
cs-mongodump
PVC to remove theclaimRef
section.oc edit pv <volume_name_from_earlier_step> -n $CS_NAMESPACE
Remove the
claimRef
section and save the PV. -
Verify the status of the PV. The status might be
Bound
orAvailable
. Wait until the status isAvailable
.oc get pv -n $CS_NAMESPACE | grep <volume_name_from_earlier_step>
-
Edit the
cs-mongodump-copy.yaml
to changemetadata.namespace
value to the new namespace where you are deploying foundational services.vi cs-mongodump-copy.yaml
The YAML file content might resemble the following content:
apiVersion: v1 kind: PersistentVolumeClaim metadata: labels: app: icp-bedrock-backup name: cs-mongodump namespace: cpns2 # target namespace where you are deploying foundational services spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: rook-ceph-test # verify that this storage class is the same used earlier in `persistentvolume.yaml` volumeMode: Filesystem volumeName: pvc-393f73e6-8b49-40f4-917c-8f5b9cbcbf20 # verify that the persistent volume name is the same that you got from earlier step
-
Create the PVC.
oc apply -f cs-mongodump-copy.yaml
-
Verify whether the new PVC is bound to the PV.
oc get pvc -n <target-namespace-where-you-are-deploying-foundational services> | grep cs-mongodump
-
Set the
CS_NAMESPACE
environment variable value with the target namespace where you are deploying foundational services.export CS_NAMESPACE=<target-namespace-where-you-are-deploying-foundational services>
-
Get the MongoDB restore script.
wget https://raw.githubusercontent.com/IBM/ibm-common-service-operator/scripts/velero/restore/mongoDB/mongo-restore.sh
-
Get the MongoDB restore job file.
wget https://raw.githubusercontent.com/IBM/ibm-common-service-operator/scripts/velero/restore/mongoDB/mongodbrestore.yaml
-
Get the MongoDB access script.
wget https://raw.githubusercontent.com/IBM/ibm-common-service-operator/scripts/velero/restore/mongoDB/set_access.js
-
Run the MongoDB restore script.
./mongo-restore.sh
-
Verify whether identity and access management (IAM) components are restored.
oc get pods -n $CS_NAMESPACE | grep auth