Skip to content

Atlas

Share your idea. In order to help prioritize, please include the following information

  1. A brief description of what you are looking to do
  2. How you think this will help
  3. Why this matters to you

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

17 results found

  1. immutable backups

    currently Atlas - MongoDB backup are stated to be immutable, however, that is not true because there is no object lock on the s3 bucket.

    We would like to request adding the option to have an object lock on the s3 bucket that our snapshots are located on which will make sure that the snapshots can only be deleted by retention and not modified or deleted by anyone else. This is to line up with WORM compliance while dealing with financial data.

    https://www.telemessage.com/what-is-worm-compliance-and-when-is-it-needed/

    https://aws.amazon.com/blogs/storage/protecting-data-with-amazon-s3-object-lock/

    8 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Admin →

    Hello,

    I am pleased to announce that we have released our backup feature called Backup Compliance Policy, that protects your backups from being deleted by any user, ensuring WORM and full immutability (can not be edited/modified or deleted) for backups automatically in Atlas.


    Backup Compliance Policy allows organizations to configure a project-level policy to prevent the deletion of backups before a predefined period, guarantee all clusters have backup enabled, ensure that all clusters have a minimum backup retention and schedule policy in place, and more.


    With these controls, you can more easily satisfy data protection requirements (e.g., AppJ, DORA, immutable / WORM backups, etc.) without the need for manual processes.


    Please note that the Backup Compliance Policy can not be disabled without MongoDB support once enabled so please make sure to read our documentation thoroughly before enabling.

  2. To not to delete the most recent backup when the DB is deleted

    After a cluster is terminated in MongoDB Atlas, the backups disappear with it. It will be good to preserve the most recent backup of this database. Otherwise, there is no point to have backup if the DB cannot be recover after accidental delete

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    completed  ·  0 comments  ·  Backup  ·  Admin →
  3. Configure --jsonFormat=canonical flag in export policy.

    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…

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    completed  ·  1 comment  ·  Backup  ·  Admin →
  4. Comprehensive Backup Ransomware Protection

    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…

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Backup  ·  Admin →

    Hello,

    I am pleased to announce that we have released our backup feature called Backup Compliance Policy, that protects your backups from being deleted by any user, ensuring WORM and full immutability (can not be edited/modified or deleted) for backups automatically in Atlas.


    Backup Compliance Policy allows organizations to configure a project-level policy to prevent the deletion of backups before a predefined period, guarantee all clusters have backup enabled, ensure that all clusters have a minimum backup retention and schedule policy in place, and more.


    With these controls, you can more easily satisfy data protection requirements (e.g., AppJ, DORA, immutable / WORM backups, etc.) without the need for manual processes.


    Please note that the Backup Compliance Policy can not be disabled without MongoDB support once enabled so please make sure to read our documentation thoroughly before enabling.


    In addition to Backup Compliance Policy, organizations can also utilize our multi-region

  5. Disable Specific API's

    For certain API's, like the ability to Delete a backup, have the ability for an Owner to disable this API call entirely, to prevent bad actors from being able to destroy a system or even a good actor from unintentionally destroying a system. If a customer has a policy that no backups shall be deleted ever, have the ability to disable this API across the board.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Admin →

    Hello,


    I am pleased to announce that we have released our backup feature called Backup Compliance Policy, that protects your backups from being deleted by any user, ensuring WORM and full immutability (can not be edited/modified or deleted) for backups automatically in Atlas. This applies to any method of deleting backups, regardless of wheter it is through the UI or the API.


    Backup Compliance Policy allows organizations to configure a project-level policy to prevent the deletion of backups before a predefined period, guarantee all clusters have backup enabled, ensure that all clusters have a minimum backup retention and schedule policy in place, and more.


    With these controls, you can more easily satisfy data protection requirements (e.g., AppJ, DORA, immutable / WORM backups, etc.) without the need for manual processes.


    Please note that the Backup Compliance Policy can not be disabled without MongoDB support once enabled so please make sure…

  6. Backup Policy change approvals

    The Backup Policy configuration shows a checkbox allowing the altered backup policy to affect all prior backups. The problem with this is that someone could accidentally (or maliciously) delete all prior backups.

    This feature request would include implementing some sort of multi level approval prior to enacting said recursive backup policy changes (affecting prior backup snapshots).

    6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Admin →

    Hello,

    I am pleased to announce that we have addressed your concern of accidental or malicious deletion of all backups in a cluster. We have released our backup feature called Backup Compliance Policy, that protects your backups from being deleted by any user, ensuring WORM and full immutability (can not be edited/modified or deleted) for backups automatically in Atlas.


    Backup Compliance Policy allows organizations to configure a project-level policy to prevent the deletion of backups before a predefined period, guarantee all clusters have backup enabled, ensure that all clusters have a minimum backup retention and schedule policy in place, and more.


    With these controls, you can more easily satisfy data protection requirements (e.g., AppJ, DORA, immutable / WORM backups, etc.) without the need for manual processes.


    Please note that the Backup Compliance Policy can not be disabled without MongoDB support once enabled so please make sure to read our…

  7. Restore snapshots on s3 back to atlas cluster

    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…

    13 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Backup  ·  Admin →

    Hello,


    I would like to update everyone on some changes we have made over the last couple of quarters that resolves multiple parts of the overall goal here, in addition to the methods Ben outlined in the past


    First, is Import Archive from S3 in Atlas. This walks you through how to import an archive from S3 back into Atlas.


    In addition to this we now have other protections around cluster and backup deletion protection to protect against human error but also to ensure you can comply with various requirements automatically in Atlas. 


    You now have an option to retain all backups when terminating an M10+ cluster.

    - When you terminated a cluster through the Atlas Ui, on the termination confirmation pop up, you will now see an additional toggle labeled "Keep existing snapshots after termination". If you select this option when terminating your cluster, all of your…

  8. Recovery after cluster delete

    Cloud Backups should be recoverable even after a cluster delete otherwise they can't really be considered backups. One way to do this would be to allow for automated backup downloads to customer specified cloud provider storage.

    6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Admin →

    Hello,


    I am pleased to announce that in Atlas you now have an option to retain all backups when terminating an M10+ cluster.


    When you terminated a cluster through the Atlas Ui, on the termination confirmation pop up, you will now see an additional toggle labeled "Keep existing snapshots after termination". If you select this option when terminating your cluster, all of your backups for that cluster will be retained.


    You can also choose to retain you backups for a cluster when deleting a cluster through the Atlas Administration API. When deleting a cluster through the API, you can include the retainBackups parameter and this will retain all of your backups after termination as well.


    You can view or use the backups from a terminated (or other active) M10+ cluster by selecting the "Backup" tab in the left side navigation of the Atlas UI.


    As I mentioned…

  9. Automatic backup outside Atlas

    For DR strategy, one need to have its backups outside Atlas.
    This can be achieved in several ways. Some are:
    - Provide APIs to download the current backups and let the customers automate this on their side
    - Write backups in the customer provided cloud account (aws s3, azure blob stroage...) My favorite option

    I found many ideas related to my needs, but they were too specific. This need is more general: just provide a way to have backups automatically outside of atlas.

    5 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  Backup  ·  Admin →
  10. Vault Lock to protect Atlas Cloud Backups

    We are currently looking for a solution to secure our Atlas backups.

    Something similar to AWS Glacier Vault Lock [1] or a simple grace period before backups are deleted once and for all would be nice.

    It would be amazing to protect the Atlas backups from being deleted.
    Currently, if one of our Atlas admins was compromised, the damage for the company would be enormously high. So we need to implement measures against the final deletion of our most mission critical data.

    also mentioned in: [2]

    [1] https://aws.amazon.com/de/blogs/security/amazon-glacier-introduces-vault-lock/
    [2] https://developer.mongodb.com/community/forums/t/is-there-a-vault-lock-for-atlas-backups/11041

    10 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Backup  ·  Admin →

    Hello,

    I am pleased to announce that we have released our backup feature called Backup Compliance Policy, that protects your backups from being deleted by any user, ensuring WORM and full immutability (can not be edited/modified or deleted) for backups automatically in Atlas.


    Backup Compliance Policy allows organizations to configure a project-level policy to prevent the deletion of backups before a predefined period, guarantee all clusters have backup enabled, ensure that all clusters have a minimum backup retention and schedule policy in place, and more.


    With these controls, you can more easily satisfy data protection requirements (e.g., AppJ, DORA, immutable / WORM backups, etc.) without the need for manual processes.


    Please note that the Backup Compliance Policy can not be disabled without MongoDB support once enabled so please make sure to read our documentation thoroughly before enabling.

  11. Atlas backup to second region

    We would like the option to have our Atlas backups automatically copied to a 2nd region to support our DR initiative. I realize we could create a live database node in a 2nd region, but that is more costly and complex. Having the backup sync to another region that we can restore off of in case the primary region fails would be simpler and more cost effective.

    Is this something that is on your roadmap, and if so, when will it be released?

    Thanks!

    169 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    32 comments  ·  Backup  ·  Admin →

    Hi Everyone!
    We are excited to officially announce the general availability of Snapshot Distribution (multi-region backups)!
    You can find it available in your clusters today. 


    It is available through the UI (at the bottom of the cluster backup policy tab called “Additional Backup Copies”) and through the API. 


    Check out our resources to learn more - Docs | Blog post.


    Sincerely,

    The MongoDB Team

  12. option to create a final snapshot before deleting a cluster

    Today when an Atlas cluster is deleted, all backups/snapshots of this cluster are deleted along with it.

    This is especially an issue when working with automation tools like terraform, where a cluster can be deleted by accident easily.

    In AWS Aurora Postgres, for example, there is an option to create a "final snapshot" before deleting the cluster.

    If this option is enabled for a cluster, whenever a user triggers the deletion of the cluster (either manually, via API, or any other method), a final snapshot will be created, before the cluster is deleted.

    This final snapshot is then available independently…

    91 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    8 comments  ·  Backup  ·  Admin →

    Hello All,


    I am pleased to announce that in Atlas you now have an option to retain all backups when terminating an M10+ cluster.


    When you terminated a cluster through the Atlas Ui, on the termination confirmation pop up, you will now see an additional toggle labeled "Keep existing snapshots after termination". If you select this option when terminating your cluster, all of your backups for that cluster will be retained. 


    You can also choose to retain you backups for a cluster when deleting a cluster through the Atlas Administration API. When deleting a cluster through the API, you can include the retainBackups parameter and this will retain all of your backups after termination as well.


    You can view or use the backups from a terminated (or other active) M10+ cluster by selecting the "Backup" tab in the left side navigation of the Atlas UI.


    At any…

  13. Change Azure snapshot backups from LRS to GRS

    Sorry but this is a must. GRS is a 2 region datacenter backup, LRS only 1. Fire or disaster will take out everything if LRS is used.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  Backup  ·  Admin →

    Hello,


    We recently released a feature that we call Snapshot Distribution which allows any Atlas user to copy their backups into additional cloud provider regions that are supported in Atlas. 


    This allows you to store the backups in whatever region you prefer automatically. In the event of a disaster in a cloud provider region, Atlas will intelligently use a backup copy in an additional region for a restore.


    You can read more about this in this blog, https://www.mongodb.com/blog/post/introducing-snapshot-distribution-atlas , and our docs, https://www.mongodb.com/docs/atlas/backup/cloud-backup/scheduling/#configure-service-to-automatically-copy-snapshots-to-other-regions .

  14. Alert when a snapshot restore succeeds/fails

    Simply send an email alert when a restore finishes (or errors).

    This is important for us because we run a restore (from prod to qa) every weekend and it takes over 14 hours. If it fails, we need to know so we can quickly kick it off again before Monday. Otherwise the QA team will be dead in the water.

    9 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Backup  ·  Admin →
  15. Provide `replSetName` vs. `snapshotId` mapping in `GET /groups/{GROUP-ID}/clusters/{CLUSTER-NAME}/backup/snapshots` Public API call for each

    What is the problem that needs to be solved? Provide replSetName vs. snapshotId mapping in GET /groups/{GROUP-ID}/clusters/{CLUSTER-NAME}/backup/snapshots Public API call for each snapshotId.

    Why is it a problem? (the pain) You're doing automated disaster recovery (restore from Atlas to on-prem via Manual Restore) scenario and you need to know which snapshotId (and its corresponding .tar.gz file) is related to which Atlas Cluster Shard/Config Server Replica Set. E.g. 5e442aa4cf09a2352527536b = Cluster0-shard-0, 5e442aa4cf09a23525275370 = Cluster0-shard-1, 5e442aa4cf09a23525275375 = Cluster0-config-0.

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    completed  ·  0 comments  ·  Backup  ·  Admin →
  16. Define Default Backup Policy

    The ability to save a custom backup policy as the default, so all new clusters don't have to be customized to meet the backup policy requirements.

    6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Admin →

    Hello,


    I am pleased to announce that we have released our backup feature called Backup Compliance Policy, that enables the ability to define a default backup policy.


    Backup Compliance Policy allows organizations to configure a project-level policy to prevent the deletion of backups before a predefined period, guarantee all clusters have backup enabled, ensure that all clusters have a minimum backup retention and schedule policy in place, and more.

    With these controls, you can more easily satisfy data protection requirements (e.g., AppJ, DORA, immutable / WORM backups, etc.) without the need for manual processes.


    Please note that the Backup Compliance Policy can not be disabled without MongoDB support once enabled so please make sure to read our documentation thoroughly before enabling.



  17. I'd like to have a scheduled mongodump backup option

    I'm coming from mLab and I'm used to having an option in my backup strategy that includes a mongodump backup as well as what Atlas calls a CPS (cloud provider snapshot). The latter is actually a snapshot of the database directory at the filesystem level, which is great for instant restores within Atlas (same or different cluster). However, the mongodump backup (from mLab as an example) allows me to backup on a regular schedule and download those backups for restores locally and elsewhere outside of Atlas.

    Yes, I can run mongodump operations myself from a system outside of Atlas, but…

    72 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    9 comments  ·  Backup  ·  Admin →
  • Don't see your idea?

Feedback and Knowledge Base