JSON does not support all data types that are available in BSON. This means that when using JSON there will be a so called "loss of fidelity" of the information.
However, using the --jsonFormat=canonical flag in a mongoexport command will preserve all available BSON data types, so the "loss of fidelity" issue can be completely avoided.

Now we plan to export our cloud backups to an AWS S3 bucket. To do this, we would like to set up an export policy to automatically export the snapshots. We could already do this via the API. However, the data is output in relaxed mode. However, because of the "loss of fidelity" issue, we need canonical mode.

MongoDB Support has already told us that there is currently no way to specify in the export policy that --jsonFormat=canonical should be used.

However, we absolutely need this format flag and in the future we will certainly not be the only ones with this request.

MongoDB Atlas needs a modern, comprehensive, secure ransomware protection strategy for its customers. Simply providing the ability to backup a database, and encrypt that database with "bring your own key" is not enough. Below I highlight what I believe are key components of a comprehensive strategy (or at least a good start).

Immutable and Verifiable Backups

Once backups are created, Atlas should provide a facility to ensure the backup remains immutable. Further, Atlas should provide verification that a backup continues to be untouched / unmodified for its entire lifecycle.

Deletion Protection

Atlas should provide enhanced deletion protection for backups. Any attacker with privilege escalation can delete backups, then take control of the database. There should be a MFA and/or multi-step/multi-person backup setting that customers can enable. This could enable a requirement of at least two factors before deleting a backup. Alternatively, it could also provide the ability to turn on a feature that would require two humans to "sign off" on the deletion of a backup.

(extra credit) Air Gapped Backups

An "extra credit" feature would be to have the ability to store a copy of each backup in an air gapped storage solution.

Hello Team,

This is Raja Selvam,

I would like to get more details on Clod backup.

Lets say suppose i would like to get yesterday's backup from one of the collection.

I do not want to restore the backup into another new cluster.
I do not want to download the backup since my Data will be around 1 TB, Incase if I go for download option this will take 1 day.

This solution also not working since we have to load the data to s3.
https://docs.atlas.mongodb.com/backup/cloud-backup/export/

Can we have option for cloud backup like legacy backup in feature. We ate tottaly blocked because of this dis adv in atlas. Even for single doc data validation we are creating a M60 cluster with 1 TB data which will take 1 to 2 hours near also cost effective.

Please provide the best solution for the same

Sample ticket : https://support.mongodb.com/case/00900476

I have a backup process that is taking hourly dumps of the oplog on my production cluster running MongoDB v.5.0.6.

It works fine using older versions of mongodump. However, when I update my tools to any version higher than 100.3.1 (100.4.x and above), my oplog backups fail with the following error:

CMD : 2022-02-16T15:39:03.186-0500  Failed: error creating intents to dump: error counting local.oplog.rs: (Location40602) $collStats is only valid as the first stage in a pipeline.

According to Atlas Support, this issue is limited to M0-M5 clusters and will need to be addressed by the Atlas development team.

Can I ask that this be looked at so that we can keep up with the latest tool and cluster versions without sacrificing our opLog backup strategy?

PITR mechanism does not allow the user to choose which snapshot to use as base before replaying the oplog. Given that Atlas does not validate the snapshots after they have been taken, the user ends up needing to setup their own validation process. That alone is not a problem. However, when one needs to use the PITR mechanism, not being able to select a previously validated snapshot may lead for PITR restores to use unvalidated snapshots.

Either Atlas should enable, uppon choosing, the validation of snapshots right after they are taken, or allow the selection of valid snapshots (snapshots taken within the range of the PITR window) to be used for PITR restores.

Without these there is no way for the user to know if the PITR mechanism reliable, and you do not want to find out it is not when you really need to restore.

Currently we store Atlas snapshots on S3 for D.R purposes as well as for compliance reasons.

There was a scenario where an instance was deleted by mistake, and once an instance is deleted all of the atlas managed backup snapshots were gone. In order to restore the Atlas instance we had to do the following:

1) create a new atlas instance

2) restore the snapshot from s3 to a temporary mongodb database and then do a dump and restore in order to migrate the data back into the new atlas instance.

This is a time-consuming process, so if there is the ability to copy the snapshots directly back to the atlas instance that will save some time.

In addition, this also can benefit a scenario where we archive/purge data on a periodic basis and if needing to restore the data back for compliance reasons we can restore the snapshot, stored in S3, taken before the purge/archive process to another Atlas instance. (with the understanding that the mongo snapshot versions are the same as what is being offered in atlas).