17 results found

1. 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

   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

   32 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
   completed  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

   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

2. 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 of the deleted cluster, so in case of accidental deletion, we can create a new cluster based on this snapshot.

   This would be a huge security and safety improvement.

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

   91 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

   8 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
   completed  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

   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 time before terminating a cluster, you can choose to take an On-Demand Snapshot, if you would like a final snapshot.

   
   

   To protect from accidentally deleting a cluster in general, you can utilize the Termination Protection setting in Atlas, which when enabled prevents users from deleting any cluster.

   
   

   In addition to these options, if you would like to protect your backups, in all scenarios, from ever being deleted before the designated retention period has ended, please learn more about our new backup feature called Backup Compliance Policy. This ensures your backups are never deleted early.

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

3. 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 having those mongodump archives available within a rolling window is really great to quickly grab a backup and examine offline or in another environment entirely, with no additional management or systems from me to do so.

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

   72 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

   9 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
   completed  ·  AdminBenjamin Cefalo (Director, Product Management, MongoDB) responded

   We have released the ability to export a snapshot to your own S3 bucket. More details here —> https://docs.atlas.mongodb.com/backup/cloud-backup/export/

4. 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 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).

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

   13 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

   2 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
   completed  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

   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 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.

   
   

   To protect from accidentally deleting a cluster in general, you can utilize the Termination Protection setting in Atlas, which when enabled prevents users from deleting any cluster.

   
   

   In addition to these options, if you would like to protect your backups, in all scenarios, from ever being deleted before the designated retention period has ended, please learn more about our new backup feature called Backup Compliance 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.

   
   

   In addition to Backup Compliance Policy, organizations can also utilize our multi-region Snapshot Distribution to automatically copy backups (snapshots and oplogs) to additional Atlas regions. If your primary cloud experiences a region outage then Atlas will be able to recover with a copied backup from another region, just like any normal restore.

   
   

   With all of these features, you can automatically  protect your data and meet compliance directly in Atlas.

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

5. 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

   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

   2 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
   completed  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

   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.

6. 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

   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
   completed  ·  AdminBenjamin Cefalo (Director, Product Management, MongoDB) responded

   In Atlas, you can now create alerts related to backup.

7. 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

   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
   completed  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

   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.

8. 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

   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
   completed  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

   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 documentation thoroughly before enabling.

   
   

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

9. 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

   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
   completed  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

   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 previously, you can also schedule automated exports of your backups to S3 in Atlas. 

   
   

   In addition to these options, if you would like to protect your backups, in all scenarios, from ever being deleted before the designated retention period has ended, please learn more about our new backup feature called Backup Compliance Policy. This ensures your backups are never deleted early.

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

10. 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

    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
    completed  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

    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.

    
    

    
    

11. 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

    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

    3 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
    completed  ·  AdminBenjamin Cefalo (Director, Product Management, MongoDB) responded

    This feature has been released, you can see how to utilize it here —> https://docs.atlas.mongodb.com/backup/cloud-backup/export/

12. 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 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.

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

    3 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
    completed  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

    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 Snapshot Distribution to automatically copy backups (snapshots and oplogs) to additional Atlas regions. If your primary cloud experiences a region outage then Atlas will be able to recover with a copied backup from another region, just like any normal restore.

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

13. 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

    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

    completed  ·  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

14. 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

    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

    completed  ·  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

15. 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 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.

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

    completed  ·  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

16. 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

    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
    completed  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

    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 to read our documentation thoroughly before enabling.

    
    

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

17. 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

    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

    3 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
    completed  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

    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 .