22 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 →
   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 →
   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 →
   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. Annual Snapshot Retention Policy Option

   I have customers that would like the ability to retain annual snapshots going back 5 or so years for compliance reasons. Currently, you can do this with monthly snapshots by retaining for 5*12 months, but then you have to store all the monthly snapshots in between.

   25 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

   7 comments  ·  Backup  ·  Delete…  ·  Admin →
   completed  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

   As of March 2024, Atlas Backups now have a yearly snapshot frequency option in the UI and API. This is also available in our Terraform MongoDB Atlas Provider v1.16.0 

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

6. efficient backup restore between MongoAtlas Projects

   Hello,

   currently, when we restore a SNAPSHOT from one cluster to another cluster in the same MongoAtas Project (example from "production" project to "production" project), this is very efficient (several minutes).

   On the other hand, if we execute the same backup restore from one cluster to another cluster on another MongoAtlas project (example : from "production" project to "staging" project), this is much less efficient and it will take several hours (instead of several minutes above).

   This is very efficient in the same MongoAtlas project because it will use cloud provider system using hard disk management.

   Could you improve efficiency of backup restore system between MongoAtlas Projects ?
   Similarly, could you do the same if cluster nodes are on different regions ?

   Thank you.
   Regards.
   David

   Hello,

   currently, when we restore a SNAPSHOT from one cluster to another cluster in the same MongoAtas Project (example from "production" project to "production" project), this is very efficient (several minutes).

   On the other hand, if we execute the same backup restore from one cluster to another cluster on another MongoAtlas project (example : from "production" project to "staging" project), this is much less efficient and it will take several hours (instead of several minutes above).

   This is very efficient in the same MongoAtlas project because it will use cloud provider system using hard disk management.

   Could you improve efficiency… more

   11 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 →
   completed  ·  AdminKaylee (Admin, MongoDB) responded

   We have released the ability to enable faster restores across projects in AWS for Atlas Backups! You can enable faster cross-project restores by clicking the “Faster Restore” button in the cluster Backup page.

   Learn more here

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

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

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

10. Allow backup download through PrivateLink

    We need the ability to download our backups via PrivateLink connection. Our clusters aren't reachable via VPC peering as we solely use PrivateLink. The existing download capability doesn't support a PrivateLink URL to download our backups through.

    7 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 →
    completed  ·  AdminKaylee (Admin, MongoDB) responded

    For Atlas clusters hosted on AWS and Azure with private endpoints configured, Atlas now enables you to download the snapshot via the private endpoints within the same region as the snapshot via both the UI and Admin API.

    
    

    Documentation can be found here.

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

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

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

    
    

    
    

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

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

16. Enable AWS EBS Fast Snapshot Restore (FSR) on Atlas

    To speed up recovery after restoring from a snapshot or having a node replaced, it would be nice to have the option to use AWS Fast Snapshot Restore

    https://aws.amazon.com/blogs/aws/new-amazon-ebs-fast-snapshot-restore-fsr/

    This would allow the disk to have full performance as soon as available.

    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 →
    completed  ·  AdminKaylee (Admin, MongoDB) responded

    We have released the ability to enable faster restores across projects in AWS for Atlas Backups! You can enable faster cross-project restores by clicking the “Faster Restore” button in the cluster Backup page.

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

18. Yearly backup option is required

    We are planning to take backup yearly , but as of now available max monthly backup. If i want to take yearly backup need to take 12 months for single year which expensive , as per our audit team need 20 years back up retention then it is required 12X20 = 240 backups which is very expensive. If yearly backup is available only 20X1 = 20 only.
    As of now only available below options:
    Hourly
    Daily
    Weekly
    Monthly

    Raised case also in our support portal: 01198437

    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 →
    completed  ·  AdminKaylee (Admin, MongoDB) responded

    Hi! We added the yearly snapshot policy option earlier this year. If you do not see it in your backup policy table under the Backup tab of your cluster's Backup page, click the "+ Add Frequency Unit" button and select "Yearly Snapshot" from the dropdown. Thank you for submitting your feedback to the team!

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

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