Atlas
- A brief description of what you are looking to do
- How you think this will help
- Why this matters to you
22 results found
-
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
MonthlyRaised case also in our support portal: 01198437
2 votesHi! 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!
-
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 votesHello,
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.
-
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 votesFor 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.
-
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 -
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 -
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 votesHello,
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…
-
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 votesHello,
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…
-
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 votesHello,
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…
-
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 votesHello,
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…
-
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 votesHi 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
-
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 optionI 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 votesThis feature has been released, you can see how to utilize it here —> https://docs.atlas.mongodb.com/backup/cloud-backup/export/
-
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 votesHello 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…
-
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 votesHello,
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…
-
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/1104110 votesHello,
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.
-
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…
11 votesWe 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
-
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 votesAs 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
-
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 votesWe 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.
-
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 votesWe 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/
-
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 votesIn Atlas, you can now create alerts related to backup.
-
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 votesHello,
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 .
- Don't see your idea?