MongoDB

Published: 01 Sep. 2026 Last updated: 01 Sep. 2026

Summary

MongoDB is a popular open-source, document-oriented NoSQL database that stores data in flexible, JSON-like BSON documents. It is widely used for its horizontal scalability, high availability through replica sets, and native support for sharding large datasets across clusters.

This Application Note discusses how to use CloudCasa to properly protect and restore MongoDB databases running in containers under Kubernetes.

CloudCasa has been tested for this application note with a MongoDB replica set deployed using the MongoDB Community Kubernetes Operator (version 0.13.0) running MongoDB Community Server 8.0.0. The information herein is expected to apply to more recent versions, and to multi-member replica sets, as well.

Backup

Note

A template MongoDB pre-backup application hook is available in the Templates tab of the Configuration/App Hooks page in CloudCasa. However, the template will need to be modified as discussed below in all but simple default configurations.

Locate your MongoDB replica set in your Kubernetes cluster. Make a note of the namespace, the MongoDBCommunity resource name, the labels set on the Pods (e.g. app=<replica-set-name>-svc), and also the container name in the Pod (e.g. mongod). You can find the resource name by running kubectl get mongodbcommunity -A, and the Pod labels by running kubectl get pods -n <namespace> --show-labels.
You will need one App Hook in CloudCasa — a Pre-backup hook that flushes MongoDB’s data to disk before the snapshot is taken. No Post-backup hook is required (see note below).

#. The application hook shown here authenticates to MongoDB using a MongoDB user’s password, read from a Kubernetes Secret in the same namespace as your MongoDB cluster. You can use an existing user and Secret that has (or can be granted) sufficient privileges, or create a new one dedicated to backups. Define the Kubernetes secret as follows:

kubectl create secret generic <secret-name> \
  --from-literal=password='<a-strong-password>' \
  -n <namespace>
The key inside the Secret should be named password by default; the key field shown in the next step lets you point to a different key name if desired.

Add a user to the spec.users list in your MongoDBCommunity custom resource (if it is not already present), granting it the hostManager role:
```
spec:
  users:
    - name: cloudcasa_backup
      db: admin
      passwordSecretRef:
        name: <secret-name>
        key: <secret-key>  # omit if the key is named "password"
      roles:
        - db: admin
          name: hostManager
        - db: admin
          name: backup
      scramCredentialsSecretName: <scram-secret-name>
```
The fsync command run by the hook requires the fsync action on the cluster resource. This is not granted by read-only roles such as read, readAnyDatabase, or even the dedicated backup role. Granting only backup will cause the hook to fail with an authorization error. Of MongoDB’s built-in roles, hostManager is the least-privileged role that grants fsync, so it must be included as shown above. backup is included alongside it to grant the additional read access to system collections that backup tools typically need; it does not grant fsync on its own. scramCredentialsSecretName may be any name not already used by another user. The Operator creates this Secret automatically to store the generated authentication credentials; you do not create it yourself.

So the application hook can read the password without it appearing in the App Hook command text, mount the Secret as a file into the mongod container by adding the following under spec.statefulSet in the same custom resource:

spec:
  statefulSet:
    spec:
      template:
        spec:
          containers:
            - name: mongod
              volumeMounts:
                - name: hook-password
                  mountPath: /var/run/secrets/cloudcasa-hook
                  readOnly: true
          volumes:
            - name: hook-password
              secret:
                secretName: <secret-name>

Apply the updated custom resource (e.g. kubectl apply -f <your-mongodbcommunity-file>.yaml) and wait for it to finish rolling out before continuing:
```
kubectl get mongodbcommunity <name> -n <namespace>
```
The PHASE column should read Running and all replica set Pods should be Ready.
Create an App Hook in CloudCasa by navigating to Configuration/App Hooks and clicking “Add App Hook”. Create a name for the App Hook, and select the type “Pre-backup”. Next set the App Selector and container name obtained in Step 1. Then set the command for this pre-backup hook to the following:
```
["sh","-c","mongosh --quiet -u cloudcasa_backup -p \"$(cat /var/run/secrets/cloudcasa-hook/password)\" --authenticationDatabase admin --eval \"printjson(db.getSiblingDB(\\\"admin\\\").adminCommand({fsync:1}))\""]
```
If you used a different MongoDB username than cloudcasa_backup in Step 4, update the -u value accordingly. If your Secret’s key is not named password, update /var/run/secrets/cloudcasa-hook/password to match the file path for the key you used.

Note

Unlike db.fsyncLock(), the {fsync: 1} admin command flushes data to disk but does not hold a lock afterward, so there is nothing to release once the backup completes. This is why no Post-backup hook is needed.
Add your Kubernetes cluster to CloudCasa if it has not been added already.

See also

For details see Adding a Cluster.
Create a backup definition following the CloudCasa User Guide. In the App Hooks section of the backup definition, add the Pre-backup hook created in Step 8. Ensure that you have selected the correct namespace where the MongoDB replica set exists.

See also

For more details on defining a backup, see Defining a Kubernetes backup job.

Restore

When creating a restore definition to restore MongoDB, ensure that you only select the namespace of the source MongoDB replica set. Optionally, you can also select the namespace where the MongoDB Operator is installed if you want CloudCasa to restore the Operator as well. Restore of the MongoDB replica set can be performed with or without the Operator present. Whether the Operator is restored or installed explicitly afterwards, it will manage the restored MongoDB instance.

Note

Ensure that you have enabled the “Include all cluster-scoped resources” switch when creating the restore definition. This will make sure that the CRD for the MongoDBCommunity custom resource is restored.

The Secrets referenced above (the backup user’s password Secret, and the Operator-managed credential Secrets) are ordinary namespace-scoped resources, so they are restored automatically along with the rest of the namespace — no extra steps are needed to keep the pre-backup hook working after a restore.