Chapter 12. Restoring an MBaaS Backup
12.1. Overview
You can back up an MBaaS by following the Backing up an MBaaS procedure. Once you have created the backup, you can restore a MBaaS to the state at the time of backup.
12.2. Requirements
- A self-managed MBaaS installation on an OpenShift platform
-
The
ocbinary has a logged in user with permission to edit deployment configurations and view persistent volumes. - A backup of the data for mongodb and Nagios services as described in Backing up an MBaaS .
12.3. What Data is Restored
- Mongodb replicaset data
- Nagios historical data
12.4. Restoring Nagios Data
Locate the Nagios persistent volume claim-name from the Nagios pod:
oc describe pod <nagios-pod-name> | grep "ClaimName:" claimName: <claim-name>
Determine the volume-name using the claim-name from step 1:
oc describe pvc <claim-name> | grep "Volume:" Volume: <volume-name>
Using the volume-name, run the following command:
oc describe pv <volume-name>
The output contains a
Sourcesection, similar to:Source: Type: NFS (an NFS mount that lasts the lifetime of a pod) Server: nfs-server.local Path: /path/to/nfs/directory ReadOnly: falseThis information describes where the data for the Nagios persistent volume is located.
Stop the Nagios pod by editing the Nagios deployment config and set
replicasto0:oc edit dc nagios
Change replicas to 0:
spec: replicas: 0
-
Restore the Nagios data by deleting the contents of the pod’s current persistent volume, then extract your backed up data into that directory. Ensure that after extraction the
status.datand related files are at the root of the persistent volume. Once the restore is complete, start the Nagios pod by editing the Nagios deployment config and set
replicasto1:oc edit dc nagios
Change replicas back to 1:
spec: replicas: 1
12.5. Restoring MongoDB Data
To restore the MongoDB data, the replicaset must be operational. If this is not the case, see the MongoDB doesn’t respond after repeated installation of the MBaaS section of this guide.
Should you encounter isses with MongoDB, see Troubleshooting MongoDB Issues.
Locate the primary Mongodb node. You must restore using the primary member of the Mongodb replicaset, you can find this by logging into any of the Mongodb nodes via remote shell:
oc rsh <mongodb-pod-name>
Connect to the mongo shell in this pod:
mongo admin -u admin -p ${MONGODB_ADMIN_PASSWORD}Check the replicaset status:
rs.status()
The node with the "stateStr" key set to
PRIMARYis the node to use in the following restoration procedure.Upload MongoDB data to the primary pod using the
oc rsynccommand:oc rsync /path/to/backup/directory/ <primary-mongodb-pod>:/tmp/backup
Tiprsync copies everything in a directory. To save time put the MongoDB data files into an empty directory before using rsync.
Import data into the Mongodb replicaset using the 'mongorestore' tool from inside the mongodb pod. Log into the pod:
oc rsh <mongodb-pod-name>
Restore the data:
mongorestore -u admin -p ${MONGODB_ADMIN_PASSWORD} --gzip --archive=/tmp/backup/mongodb-backup.gzFor more information on this tool, see the mongorestore documentation.
12.6. Confirming Restoration
Log in to the Studio and ensure that all the projects, environments and MBaaS targets are correctly restored.

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.