AdminBenjamin Cefalo
(Director, Product Management, MongoDB)
My feedback
-
1 vote
An error occurred while saving the comment -
7 votes
An error occurred while saving the comment Hi, thanks for the comments. A few things, first the intention of this feature is for long-term archival to meet a compliance requirement. In the near future, we will release something new to archive DR all contained in Atlas.
Secondly regarding restoring from these archives. There are two other ways you could do this. The first is to use Atlas Data Lake to query the archive directly or secondly follow the instructions here --> https://docs.atlas.mongodb.com/backup/cloud-backup/import-archive/
-
2 votes
An error occurred while saving the comment Hello, thanks for posting this. Depending on how you have configured federation this can be prevented. Can you please submit a support ticket so we can assist you?
Thanks
-
17 votes
An error occurred while saving the comment While this might be something we do in the future, we now have the ability to perform an export of the snapshot which is a much better archive for long retention. See https://docs.atlas.mongodb.com/backup/cloud-backup/export/
-
1 vote
An error occurred while saving the comment Hi Brian, because we support the Google Authenticator standard, you can use 1password to capture the QR code and store the MFA in 1password.
-
2 votes
An error occurred while saving the comment If the Azure region supports it we use ZRS, not LRS. We are working on some other functionality in the future to give you choice on backup location.
-
1 vote
An error occurred while saving the comment Hi... that's not necessarily correct. Snapshots are incremental in nature. So in theory for a short retention period such as a day, having 24 snapshots vs a few hours shouldn't actually affect the price as we don't charge on a per snapshot basis. Secondly, if you need one-hour granularity, Continuous cloud backup could be better suited for your use case.
-
22 votes
An error occurred while saving the comment Hi Tiago,
I am planning on re-introducing the queryable button with cloud backup in the future, which will make what you described not necessary. Stay tuned!
-
33 votes
An error occurred while saving the comment Hello,
We are planning on building a new version of queryable for Cloud Backup but not with a tunnel. In the meantime, I would suggest provisioning a new cluster, restoring the backup, do what you need, and then tear it down. Cloud Backup restores are extremely fast. This would be the best way for the time being.
-
1 vote
An error occurred while saving the comment Hi, You can accomplish this today, there is a setting in the organization. See https://docs.atlas.mongodb.com/tutorial/manage-organization-settings/#require-two-factor-authentication
If you however are using Federated Identity or Google Auth, this setting doesn't apply.
-
2 votes
An error occurred while saving the comment During the restore process, we have the metadata of which CMK was used during the time the backup was taken. So even if the CMK used is not the active one, as long as the IAM User you have provided still has access to the key, i.e. you haven't deleted the key from KMS, we will be able to restore the snapshot.
-
1 vote
An error occurred while saving the comment Hi Josh, this is available today. You can restore a snapshot from one cluster in a project to a cluster in another project.
https://docs.atlas.mongodb.com/reference/api/cloud-provider-snapshot-restore-jobs-create-one/
-
2 votes
An error occurred while saving the comment Today you can achieve this from the IDP side by not giving everyone access to the application
Thanks for this.
First, snapshots are immutable by default. There is no way to edit a snapshot, regardless of who you are. Secondly, on your air-gapped comment, you have options today. 1) you can download your snapshots and store them wherever you like. 2) you can use export snapshot https://www.mongodb.com/docs/atlas/backup/cloud-backup/export/
On your other point, 100% agree and stay tuned :-)