What are peoples best practices for MongoDB and disaster recovery?

What I'm interested in is less around resilience (we have replica sets - and are looking at SaaS solutions too) but more around getting the the Mongo service back after data corruption, for example one a pesky developer deletes MongoDB data from production and it replicates around all the nodes.

Are people architecting their solutions to offer Recovery Point Objectives (RPO) to a similar level as they would with SQL (so down to minutes of data loss of data) perhaps using something like Mongo Atlas for on-premise, or is 24 hours of xDB data being lost considered acceptable - as you might get as default from Mlabs?

I appreciate this differs on a customer by customer basis I'm just after a feel of what other partners feel is best practice in this space.

  • I'm voting to close, DR for Mongo would best be asked on a Mongo specific site and acceptable data loss is opinion based, what's acceptable for an e-commerce site will be vastly different for a brochureware site.
    – jammykam
    Commented Oct 31, 2016 at 19:14
  • 3
    I disagree. It's a valid question with a lot of interest; it's not simply a 'mongo' question it's a 'Sitecore with Mongo' question. As an enterprise product you'd expect brochureware to be a smaller part of its base. xDb sits at the heart of Sitecore and we should have best practices around its data integrity. Commented Oct 31, 2016 at 20:22
  • I'm sure this is obvious, but you should probably never let developers have direct access to production databases at all. They should be working off a DEV and possibly UAT cluster, and for safety (and GDPR) not even has read access to PROD databases. Commented Nov 19, 2020 at 14:46

2 Answers 2


Currently, for enterprise installations of MongoDB, the Sitecore Best Practice for Disaster Recovery of Mongo rests solely on the Best Practices of MongoDB specifically and are not entirely different for Sitecore applications.

That being said... there are some things to consider:

Answering Your Specific Question

Are people architecting their solutions to offer Recovery Point Objectives (RPO) to a similar level as they would with SQL (so down to minutes of data loss of data) perhaps using something like Mongo Atlas for on-premise, or is 24 hours of xDB data being lost considered acceptable - as you might get as default from Mlabs?

RPO objectives are going to be tied directly to the amount of data a particular client is storing in xDB. Default configurations, you would probably get away with RPO of an hour or two, if Sitecore Analytics is being utilized lightly.

If lots of custom goals, interations, and contact facets are in play and updated frequently, you may need an RPO that is pretty short, down to 15 minutes. I, personally have not implemented an RPO on mongoDB that is that short. Typically I have used 1 hour as the cut off, which is the same as I use for SQL Server full backups. (SQL Server Transaction logs are cut at 15 minutes in high volume content management implementations)

Some off the cuff thoughts:

  • The Sitecore Reporting Database, which is created through aggregation, has a deep connection to the MongoDB database. If MongoDB goes down, or the collection is deleted, this can cause a disconnect in analytics in the reporting database, which, depending on the severity, may require the reporting database to be rebuilt.

  • In addition, in the specific event of a collection being deleted, Sitecore/MongoDB will automatically start building upon a NEW collection almost instantaneously. Which may hide any issues with MongoDB until you start clicking around Experience Profile or Experience Analytics.

  • If MongoDB as a service goes down, the Sitecore Content Delivery servers will cache any interactions and events happening while MongoDB is down, hoping that nothing happens to the Content Delivery servers. AS soon as a MongoDB endpoint is available, Sitecore CD's will flush the cached data received.

The other part of your question is asking about specific tools or services. I don't want this answer to come off as too sales-y and I don't have experience with any third party tools outside of the tools that MongoDB provides.

Therefore, the rest of this answer is really going to answer your question about MongoDB best practices in general.

Background Information on MongoDB DR Best Practices

The architecture of mongodb -at a very high level- is not unlike that of SQL Server. Both have a file representation of a binary database/collection. Both have processes for backing up/dumping said databases and collections.

So at a high level, you want to make sure that you are performing the same steps for MongoDB that you are for SQL Server. Also, important to note, that how you go about performing these steps can differ depending on both your version level of MongoDB as well as whether you are using MongoDB Cloud or a MongoDB Instance.

So then the questions really become,

  • How do you backup MongoDB?
  • How do you restore MongoDB?
  • Are there tools to handle this?

The answer to all of these questions can be explained in the following list of tools that are available.

In addition, MongoDB also has some really great white papers specifically talking about this subject:

MongoDB Tools

MongoDB Cloud Manager

MongoDB Cloud Manager continually backs up MongoDB replica sets and sharded clusters by reading the oplog data from your MongoDB deployment. MongoDB Cloud Manager creates snapshots of your data at set intervals, and can also offer point-in-time recovery of MongoDB replica sets and sharded clusters.

MongoDB Ops Manager

With Ops Manager, MongoDB subscribers can install and run the same core software that powers MongoDB Cloud Manager on their own infrastructure. Ops Manager is an on-premise solution that has similar functionality to MongoDB Cloud Manager and is available with Enterprise Advanced subscriptions.

Probably the industry standard of managing MongoDB in general, including Disaster Recovery is to utilize the Mongo Ops Manager that is available in MongoDB Enterprise Advanced.

Manual Backup with mongodump

mongodump reads data from a MongoDB database and creates high fidelity BSON files which the mongorestore tool can use to populate a MongoDB database. mongodump and mongorestore are simple and efficient tools for backing up and restoring small MongoDB deployments, but are not ideal for capturing backups of larger systems.

Backing Up File System Snapshots

You can create a backup of a MongoDB deployment by making a copy of MongoDB’s underlying data files.

In Summary

As you can see, the best practices for protecting MongoDB are not unlike similar procedures that you would use with SQL Server or any other database like collection architecture. More information is readily available at MongoDB's website.

In the event that you do have to restore a MongoDB to a point in time, validate that aggregation and processing is functioning normally and that no errors are in the Sitecore logs. If something gets out of sync where there might be more data in the reporting database than in MongoDB, you may be required to rebuild your reporting database.

Hope this helps!

  • 1
    Marking this as the answer as it gives the broadest information on the options and tallies with my findings. I guess one key thing here is to understand the customers data requirements early and plan accordingly. MongoDb enterprise and Ops Server have associated costs which customers might be frustrated if sprung on; for U.K. and Europe some data protection rules apply too so cloud manager backups to US might be something to be aware of. Commented Nov 2, 2016 at 7:25

I would say it depends on the type of interactions you are capturing and frequency of aggregation.

If you are simply using it for personalization and building a 360 degree customer profile as most people do, you can possibly get away with a couple of cycles of peak traffic (if not more) which may be even more than 24 hrs. Using "Continuous Sync" to keep your reporting DB up to date maybe sufficient in this case. I would recommend looking at new vs returning visitor analytics to define the acceptable number of peak traffic cycles. Another thing to consider here maybe the "Decay Rate" set on your personas.

But if you are using it for capturing and aggregating more time sensitive interactions such as telemetry data or providing high availability data such as user profile management or low latency requirement such as fraud detection, you will definitely need high availability down to a couple of mins if not even milliseconds in some cases. Here you may need to consider resilience and read and write availability. The good thing about NoSql is the ability to write even if some of clusters become unavailable so you can aggregate later. Hope this helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.