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.

We have a scheduled process which starts up a GCE instance with both an internal and external IP address. This runs a script which:

• uses the Mongo API to get the id of the latest snapshot
• uses the Mongo API to create a restore job with HTTP delivery
• downloads the backup and perform some verification processes on the backup.

Currently Mongo Cloud only allows access to the Mongo API and the HTTPS download over the public Internet. This requires adding Google Cloud IP addresses to both the API key IP Access List and the Network Access IP Access List. It also incurs costs at our end for external IP addresses or Cloud NAT and (presumably) at the Mongo end for Internet egress.

In contrast, our GCE hosted application is able to access our database in Mongo Cloud over a VPC, which is simpler, more secure and probably cheaper and more reliable.

My suggestion for improving the platform is that Mongo Atlas API and restored snapshot HTTP delivery should be possible over VPC as well as over the public Internet.

Thanks,

Christopher Hoskin

An option should be provided to allow a user to take a snapshot of the destination cluster of a Cloud Backup restore before the restore is performed so that they can easily "revert" the restore if they need to (by just requesting a restore using the snapshot that was taken just prior).

It's possible to be in a situation where you've selected an incorrect snapshot for restoring or that you'd supplied the incorrect cluster for the snapshot to occur (this is less likely to happen in the UI than it is to happen programmatically via the API). Taking a snapshot just before restoring would mitigate the risk of these restore operations by allowing a fallback snapshot to restore from.

When I select the maintenance filter on the activity feed all the daily snapshots show up. I feel like there should be a backup screen that shows all the snapshots on the activity feed. this would make the maintenance screen more precise and relevant.

. The maintenance screen should only show what software maintenance goes on the atlas clusters. This should also include all the release fixes. so, I do not have to go to your
https://docs.mongodb.com/manual/release-notes/software releases page.

It is very hard to tell what maintenance will be applied in a given time period. We have timeframes to apply maintenance on dev and qa regions prior to production but that is not easy to control on atlas.

I would like to have more advance warning of the maintenance and exact details of what fixes are going on in the activity log and email alert I have set up.

Sometimes I have no idea what is being applied to my Banking application or get the no maintenance needed a day before it is supposed to be applied.
We need to Change control any maintenance, which is impossible to do with the limited information I get on mongo atlas.

Currently, you can put in a OPLOG TIMESTAMP value that exceeds the maximum / minimum value for the Continuous Backup Time Window.

For example, on the "Date & Time" tab of the "Point in Time Restore" menu, you are given a warning that specifies: "You can only restore to a specific point in time after MM/DD/YYYY HH:MM"

This should be added to the "OPLOG TIMESTAMP" tab where a warning could be given such as "You can only restore to a specific point in time after XXXXXXXXXX" (Epoch time).

As such, you should enforce data form validation so that a user cannot enter a timestamp that exceeds this minimum Epoch value. Data form validation should also be added to the "Date & Time" tab, as you are currently able to enter values into the HH:MM field such as 99:200 which are not valid Hour / Minute values.

Additionally - when the user enters an Epoch timestamp, the UI should calculate and render the correlation Human-Readable Date/Time and display a message similar to "Atlas will restore database to Friday, June 5, 2020 11:37:00 PM EST".

Lastly - UI should include help information in regards to the "increment" value, how it is used, and what the minimum / maximum values can be.

These changes will ensure there is no confusion or ambiguity on exactly when the database will be restored to.