Atlas
- A brief description of what you are looking to do
- How you think this will help
- Why this matters to you
74 results found
-
GCP Export Cloud Backup Snapshot support
Currently "Export Cloud Backup Snapshot" is a really good feature for off-line backups, but it only supports S3. This is quite limiting for organisations that don't use AWS. It would be really good if it also supported GCP Cloud Storage.
37 votes -
Restore indexes from AWS S3 snapshot.
While working with export snapshot to AWS S3, I found there is no way to restore indexes from metadata.json, along with data there must be opportunity to restore indexes as well otherwise have to rely on custom solutions and this may include external dependencies.
2 votes -
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 -
Allow disabling TTL Monitor (to allow restoring a snapshot)
Problem:
If you are restoring a snapshot to check the data, or to look at old data, and the collection has a ttl index, then a snapshot, once restored, will immediately mark a bunch of records for deletion, thus making it impossible to examine, export, or otherwise use that data.Solutions recommended by support include a) download the snapshot (which is very large) and load it on a local instance with the ttl monitor disabled. b) open a ticket to ask for the ttl monitor to be disabled on a target cluster, however once complete you also need to ask…
2 votes -
Backup snapshots on a single database or collection
I would like to be able to configure backup snapshots of a single database or collection on a schedule or continuously. This feature would help projects that need snapshots but only on a subset of data. Cluster-level, topology dependent snapshots may not be appropriate or make sense financially for all projects.
30 votes -
Copy/move snapshots from a source to a target cluster
It is recommended that restoring a cluster must either:
1) Restore to a new Atlas cluster and reconfigure your application to use that new cluster once the new deployment is running, or,
2) Ensure that the target Atlas cluster cannot receive client requests while you restore data.
(src https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore/#prerequisites)While doing a PIT restore with the source and target cluster being the same, our clusters have gone into a "down" state 3 times due to obscure errors, opslog not being large enough, or writes happening to the cluster during restore.
We would like to take the safer route of…
3 votes -
e-2-e mongo s3 export encryption
Dear Atlas Team,
Regarding https://www.mongodb.com/docs/atlas/backup/cloud-backup/export/ would it be possible to have the option of e-2-e encryption so that we just provide you with public key ?
1 vote -
Restore atlas cluster backup to differently encrypted Project
If we take a volume snapshot backup from one project which is encrypted with encryption key A, we need to restore it into another project with Encryption key B .
If we use Live migrate for this, it may take more time than volume snapshot restore.
We need this feature for quicker refreshes of database cluster.8 votes -
Make S3 backups configurable though the Atlas UI
It's possible though the API but for ease why not make it possible to configure automated export to S3 on backup schedules though the Atlas UI online
1 vote -
Add tunnelling to allow querying Cloud Backup snapshots
The Legacy Backups have a feature to allow connecting (tunnelling) to a snapshot to query it. This allows querying a database snapshot which is great for quickly inspecting data in the past for troubleshooting. This would be handy to have for the Cloud Backups. With Cloud Backups instead I now have to download a snapshot, load it temporarily on a cluster and remove it when done.
55 votes -
Need granular export details while exporting cloud backup to aws
Right now we get the notification when the cloud backup is successfully exported to AWS S3.
We need some granularity details in the notifications such as no of collections, size of collection/db, etc...
2 votes -
Allow OpLog Backups in Atlas M0-M5 Shared-Tier clusters running on MongoDB v.5.x
I have a backup process that is taking hourly dumps of the oplog on my production cluster running MongoDB v.5.0.6.
It works fine using older versions of mongodump. However, when I update my tools to any version higher than 100.3.1 (100.4.x and above), my oplog backups fail with the following error:
CMD : 2022-02-16T15:39:03.186-0500 Failed: error creating intents to dump: error counting local.oplog.rs: (Location40602) $collStats is only valid as the first stage in a pipeline.According to Atlas Support, this issue is limited to M0-M5 clusters and will need to be addressed by the Atlas development team.
Can I ask…
1 vote -
Option to restore one or more db from snap to cluster. Right now, it involves manual dump and restore
Currently we can only restore full cluster from backup like snap using GUI interface. If we want to restore one or more specific db, it needs manual dump and restore from backup. if we have an option to restore specific db to cluster through GUI interface, it will be very useful.
131 votes -
PITR should allow to choose which snapshot to use as base
PITR mechanism does not allow the user to choose which snapshot to use as base before replaying the oplog. Given that Atlas does not validate the snapshots after they have been taken, the user ends up needing to setup their own validation process. That alone is not a problem. However, when one needs to use the PITR mechanism, not being able to select a previously validated snapshot may lead for PITR restores to use unvalidated snapshots.
Either Atlas should enable, uppon choosing, the validation of snapshots right after they are taken, or allow the selection of valid snapshots (snapshots taken…
2 votes -
when making backups don't have the banner say "deploying your changes"
I was very confused recently when I logged in and saw the message "We are deploying your changes" despite nobody having made any changes to the cluster. Apparently what was happening was our scheduled backup was happening. This was a really confusing message to be seeing and resulted in a support request to work out what changes were being made.
It would be much better if the message when a scheduled backup was happening was more clear about what is happening and less misleading.
1 vote -
snapshots without indexes
It would be great to have the option to save Atlas backup snapshots without indexes. When using TTL indexes, when the data is restored, it is automatically removed because it is expired. Being able to create snapshots without indexes would save a lot of time to the current workaround.
6 votes -
Delete documents from backups
Allow to delete documents from existing backups based on a query.
When off-boarding customers, we sometime need to delete all of their data, including historical data from backups. Having the ability to clean up those backups, without having to restore, delete, and take a new backup, would be amazing.
1 vote -
Alert for backup policy changes
It would be great to have an alert that notifies you when someone edits the backup policies.
This would be good to validate and everyone to be aware of, because a bad change can cause major problems if it is necessary to restore a backup.
11 votes -
Cloud Manager backups support for Mumbai region(ap-south-1)
Currently Cloud mongo support for backup in below 6 regions only, Can you please start support for the Mumbai region also(ap-south-1).
1) eu-west-1 - Europe (Ireland)
2) ap-southeast-2 - Asia Pacific (Sydney)
3) eu-central-1 - Europe (Frankfurt)
4) eu-west-2 - Europe (London)
5) us-east-1 - US West (N. California)
6) us-west-2 - US East (Ohio)1 vote -
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…
8 votes
- Don't see your idea?