74 results found

1. Allow to change defaultWriteConcernSource to global to avoid flipping the flag

   Customers experience following error messages due to the defaultWriteConcernSource mismatch between the source and target cluster when restore the snapshot.

   Error: Can not restore a snapshot with custom default write concern 1 to a cluster that does not have a custom default write concern.

   Error: Can not restore a snapshot with custom default write concern majority to a cluster that does not have a custom default write concern.

   Ability to directly change the defaultWriteConcernSource without flipping between w:1 and w:majority will be convenient for the users.

   Option location:

   Cluster > configuration > Additional Settings >
   More Configuration Options > Default Write Concern

   Thanks.

   Customers experience following error messages due to the defaultWriteConcernSource mismatch between the source and target cluster when restore the snapshot.

   Error: Can not restore a snapshot with custom default write concern 1 to a cluster that does not have a custom default write concern.

   Error: Can not restore a snapshot with custom default write concern majority to a cluster that does not have a custom default write concern.

   Ability to directly change the defaultWriteConcernSource without flipping between w:1 and w:majority will be convenient for the users.

   Option location:

   Cluster > configuration > Additional Settings >
   More Configuration Options > Default… more

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Backup  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Permit downloading of serverless instance snapshots.

   Currently this is not supported. The consequence is that there is no way to restore just a single database or collection from a snapshot. This obviously greatly reduces the value of snapshots.

   •  

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Backup  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Allow turning off backups on serverless and free instances

   We have a use case where we would have liked to use a serverless instance but cannot since we cannot disable backups on serverless instances.

   We can't enable backups on this specific instance because of data retention restrictions so being able to turn them off completely on serverless and free instances would be ideal.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Backup  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. Restore indexes from AWS S3 snapshot.

   While working with export snapshot to AWS S3, I found there is no way to restore indexes from metadata.json, along with data there must be opportunity to restore indexes as well otherwise have to rely on custom solutions and this may include external dependencies.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Backup  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. Allow disabling TTL Monitor (to allow restoring a snapshot)

   Problem:
   If you are restoring a snapshot to check the data, or to look at old data, and the collection has a ttl index, then a snapshot, once restored, will immediately mark a bunch of records for deletion, thus making it impossible to examine, export, or otherwise use that data.

   Solutions recommended by support include a) download the snapshot (which is very large) and load it on a local instance with the ttl monitor disabled. b) open a ticket to ask for the ttl monitor to be disabled on a target cluster, however once complete you also need to ask for the ttl monitor to be enabled, as otherwise "...eventually, the sessions collection may become full". This means that examining backup data now has multiple support delay loops involved.

   We need a way to restore a snapshot so that we don't lose data to the ttl monitor, without requiring support involvement.

   Possible Proposed Solutions:
   - Allow project owners to disable the TTL Monitor for a cluster, OR
   - Allow restoring a snapshot to include an option to disable TTL monitor for [ select a duration | v ], OR
   - Allow a new cluster, on creation, to be created with the ttl monitor (permanently?) disabled (and some other mechanism clearing the sessions or anything else thats necessary) ,OR
   - some other solution to allow marking a restore as "don't allow restored records to be ttl'd out"

   • It might also be useful to provide a mechanism for cleaning the sessions while the TTL Monitor is disabled

   Why this matters to me:
   - We tried to pull data from a backup to calculate a longer history and didn't realize that the data was being deleted while we were trying to export the data, which meant we provided bad info.
   - There was no real way for us to restore quickly - best case is a several hour delay after creating a cluster to restore to.
   - Without some solution here, relying on snapshots as backups seems really.... bad, and needlessly slow to recover.

   Problem:
   If you are restoring a snapshot to check the data, or to look at old data, and the collection has a ttl index, then a snapshot, once restored, will immediately mark a bunch of records for deletion, thus making it impossible to examine, export, or otherwise use that data.

   Solutions recommended by support include a) download the snapshot (which is very large) and load it on a local instance with the ttl monitor disabled. b) open a ticket to ask for the ttl monitor to be disabled on a target cluster, however once complete you also need to ask… more

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Backup  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. Need granular export details while exporting cloud backup to aws

   Right now we get the notification when the cloud backup is successfully exported to AWS S3.

   We need some granularity details in the notifications such as no of collections, size of collection/db, etc...

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Backup  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. PITR should allow to choose which snapshot to use as base

   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.

   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… more

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Backup  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. Delete documents from backups

   Allow to delete documents from existing backups based on a query.

   When off-boarding customers, we sometime need to delete all of their data, including historical data from backups. Having the ability to clean up those backups, without having to restore, delete, and take a new backup, would be amazing.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Backup  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. API access over VPC

   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

   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… more

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Backup  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. Replay the point-in-time-restore journal for debug/diagnosis

    When performing a forensic analysis for the purposes of a restore, in order to determine the appropriate point in time when our data was last "sane", it would be awesome if we could start with a point-in-time restoration, and play the journal forward, e.g. performing a bisect on the data.

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. Helpful error message when restoring backup

    When I recently attempted to restore a db backup I got a cryptic error message stating "Error: Cluster Not Found"--which was extremely confusing considering that I pressed the restore button in the backup options. After some great tech support, I added my user as project owner and everything worked fine.

    Please make the error message clearer in both the Restore and Download backup scenarios.

    •  

    •  

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Backup  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. Dynamically Calculate Timestamp Limits for Continuous Backup Restore (via OPLOG Timestamp)

    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.

    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… more

    •  

    •  

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. Add colors to Backup times

    Hi can I suggest a feature to the developers? Can the developers add colors to the Backup times? Because I have accidentally Backup an instance at 3:21 PM instead of a 3:21 AM I wanted. The colors will definitely help prevent such accidents from happening. It would also be nice if the developers can ensure that Backup times are not the same for AM and PM. Thanks!

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

14. bulk delete backups

    Allow bulk deletion of backups on both active and terminated clusters through the Atlas web UI. It is currently quite cumbersome so delete them one by one if needed.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

15. Allow Exporting Snapshots when using Encryption At Rest w/ Private Endpoint
    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. Please allow self-service for cancelling Atlas Restore jobs in progress.

    Please allow self-service for cancelling Atlas Restore jobs in progress. Going through Support results in delays and is not practical.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. Support for folders with snapshot export bucket

    When creating a snapshot export in Atlas, there isn't any support for storing exports in specific folders, i.e. bucketname/mongodbatlas/exportedsnapshots. Instead, the exports have to be stored in bucketname/exported_snapshots.

    This creates an issue for posterity, which could in-turn result in data being accidentally deleted.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. Read-only access to project snapshots

    Create a role that allows less-privileged users to download project snapshots.

    Project Owner rights are currently required in order to simply download a project snapshot. Our team needs to pull snapshots in a variety of contexts, for development and offline analysis -- especially from projects associated with our non-production environments -- and we have to harass our administrators each and every time. It's frustrating to everyone involved.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. e-2-e mongo s3 export encryption

    Dear Atlas Team,

    Regarding https://www.mongodb.com/docs/atlas/backup/cloud-backup/export/ would it be possible to have the option of e-2-e encryption so that we just provide you with public key ?

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Allow OpLog Backups in Atlas M0-M5 Shared-Tier clusters running on MongoDB v.5.x

    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?

    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… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating