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 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.
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.
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.
You can create a backup of a MongoDB deployment by making a copy of
MongoDB’s underlying data files.
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!