Cloud Native Enterprise Data Management with Tardigrade for MongoDB

MongoDB and Tardigrade are excited to collaborate and demonstrate managing data backups and migrations across multiple computing and storage platforms with enterprise security and SLAs. Tardigrade, the new S3-compliant storage solution from Storj Labs, can easily be configured to store all your database backups and snapshots from MongoDB Ops Manager, the management platform for enterprise MongoDB deployments. In this post, we’ll give an overview of how all this works in cloud-native environments. For this, we’ll install the entire MongoDB Enterprise stack into a Kubernetes cluster along with a small gateway app from Tardigrade and we’re ready to go!

Most companies have multiple engineering teams supporting multiple apps. These apps need data services and specifically require dynamic provisioning of new environments along with integrated platform management in order to continuously support their businesses. Each application, then, in turn, has its own requirements for security, high-availability and disaster recovery scenarios. We can combine tech from MongoDB and Tardigrade to support all these variable requirements.

The best part of Tardigrade is the service includes features by default that would otherwise cost organizations a large premium. For example, all data stored on Tardigrade is end-to-end encrypted by default, meaning you don’t have to do any special configuration or run any special software to keep your database backups and snapshots safe, private, and out of the hands of would-be hackers.

Every file uploaded to Tardigrade also has cross-geography redundancy by default, which is similar to a multi-region cloud backup architecture. This means your cloud storage backups will always be accessible, and a single outage won’t cripple your operations like it would in a centralized cloud storage architecture. Tardigrade backups are available everywhere, and with hot availability, developers can quickly rehydrate their MongoDB instance from anywhere in the world.

In addition to being half the cost of centralized cloud storage services, Tardigrade is also more affordable should you need to access your data. Egress bandwidth is half the price of Google Cloud, Amazon S3, and Azure and even more affordable than centralized backup architectures, which generally charge a hefty premium should you need to access your data.

MongoDB Enterprise supports a variety of cloud-native deployment options. This gives you and your apps access to locally deployed MongoDB clusters alongside direct access to MongoDB clusters running in the MongoDB Atlas cloud. Enterprises can now offer controlled access to advanced MongoDB data platform features directly to developers and CI/CD pipelines. Figure 1 depicts the overall architecture.


To see how all this works, we’ll spin up a deployment on GKE with everything. With this setup, we can create MongoDB clusters, managed by MongoDB Ops Manager. The entire deployment automates the configuration of an S3-compliant bucket to store backups.

Key Technologies

  • MongoDB Enterprise Kubernetes Operator
  • MongoDB Enterprise Ops Manager

  • S3-gateway - Tardigrade
  • Kubernetes

This example presents a v3 Helm chart which installs a complete MongoDB Enterprise database-as-a-service platform. There is a subchart for installing the Tardigrade S3-gateway to store backups and snapshots along. There are a number of components in this deployment. The workloads view in GCP shows the main ones:

This entire setup and more can be found in this repository Note the special Helm chart in total-cluster/addons/tardigrade-gateway to set up communication between our private Kubernetes cluster and the Tardigrade decentralized cloud storage service.

Your first step is to procure a Kubernetes cluster. A couple of examples can be found in the total-cluster/quickstarts folder, but most any cluster should work. This full example will require 5 to 7 worker nodes with 2 nodes having at least 8 GB of ram.

Next, set up your Tardigrade Gateway. Check out the details for that over in the gateway chart in total-cluster. Installing the chart (Note: requires Helm V3),

➜  addons git:(master) ✗ helm install s3-gateway tardigade-gateway 
NAME: s3-gateway
LAST DEPLOYED: Sat May 30 07:52:43 2020
NAMESPACE: total-cluster
STATUS: deployed

Here, we can inspect the cluster and see our local gateway running. This service provides a local secure connection for MongoDB Ops Manager to write database backups.

➜  addons git:(master) ✗ kubectl get all --selector='app=s3-gateway-tardigrade-gateway'
NAME                                                 READY   STATUS    RESTARTS   AGE
pod/s3-gateway-tardigrade-gateway-68fbf4b4d7-4qbvt   1/1     Running   0          104s

NAME                                        TYPE        CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/s3-gateway-tardigrade-gateway-svc   ClusterIP <none> 7777/TCP   104s

NAME                                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/s3-gateway-tardigrade-gateway   1/1     1            1           104s

NAME                                                       DESIRED   CURRENT   READY   AGE
replicaset.apps/s3-gateway-tardigrade-gateway-68fbf4b4d7   1         1         1       104s

Once your gateway is set up and running, install the entire MongoDB data platform with the total-cluster chart.

git clone
helm install mongodb total-cluster

The entire chart takes between 5 to approx 10 mins to finish installing. This is because it’s installing quite a few components.

Ops Manager needs to be configured to use the gateway. You can connect to your Ops Manager with a basic port-forward command like this,

kubectl port-forward mongodb-ops-manager-0 8080:8080 

Connect your browser to localhost:8080 and use and MongoDB12345% to login.

Note: These credentials are stored in a secret, called mongodb-ops-manager-secret. You can update this in the chart. Also note the “mongodb” in the secret name comes directly from the Helm release name.

You should see your MongoDB cluster once connected:

Setting up the S3 Blockstore pointing to local gateway

You can configure backups for your app databases following this guide: Backup Overview.

Screen shot of backup taking place.

Finally, you can see the backup data blocks stored in the Tardigrade bucket. You can even use the local tardigrade-gateway with command s3 command line tools:

$kubectl port-forward tardigrade-gateway-tardigrade-gateway-75cfdb889-nz2n4 7777:7777 &
$aws --endpoint-url http://localhost:7777 s3 ls test

The Ops Manager extensive API can be used to automate backup restoration along with many devops tasks.


We look forward to seeing what MongoDB users do with Tardigrade. We regularly hear from users who would like cloud backup services that provide end-to-end encryption, multi-region redundancy, as well as lower and more predictable costs compared to centralized services. While relatively new, Tardigrade delivers on all of these needs, while still offering the same enterprise service level agreements users absolutely require.

Learn more