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 oc binary 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

  1. Locate the Nagios persistent volume claim-name from the Nagios pod:

    oc describe pod <nagios-pod-name> | grep "ClaimName:"
    claimName: <claim-name>
  2. Determine the volume-name using the claim-name from step 1:

    oc describe pvc <claim-name> | grep "Volume:"
    Volume: <volume-name>
  3. Using the volume-name, run the following command:

    oc describe pv <volume-name>

    The output contains a Source section, 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:  	false

    This information describes where the data for the Nagios persistent volume is located.

  4. Stop the Nagios pod by editing the Nagios deployment config and set replicas to 0:

    oc edit dc nagios

    Change replicas to 0:

    spec:
      replicas: 0
  5. 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.dat and related files are at the root of the persistent volume.
  6. Once the restore is complete, start the Nagios pod by editing the Nagios deployment config and set replicas to 1:

    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.

  1. 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 PRIMARY is the node to use in the following restoration procedure.

  2. Upload MongoDB data to the primary pod using the oc rsync command:

    oc rsync /path/to/backup/directory/ <primary-mongodb-pod>:/tmp/backup
    Tip

    rsync copies everything in a directory. To save time put the MongoDB data files into an empty directory before using rsync.

  3. 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.gz

    For 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.