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

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.

After an incident I may single out a snapshot and decide it is important. At this point I am able to change the retention policy to keep it for a longer time.

It would be useful to also be able to add a note or a description to that snapshot so that I may tell future me why that snapshot was important and what incident it is tied to.

Right now I have to give an admin permission to allow someone on my team to query snapshots from a backup (i.e. downloading the tunnel file).
I don't want to give an admin permission just to allow our data analysts or a developer trying to understand data corruptions to view the database at an older date.

seems like a potential enhancement for the snapshot schedule to consider cpu/connection/etc load metrics before deciding to run or not

When viewing Cloud Provider Snapshot information, all dates are listed in the time zone on the User's profile. However, the date/time to be entered when trying to perform a PIT restore has to be entered in UTC time. This is asking a lot of someone who is probably already really nervous to be able to correctly calculate the difference between their time zone and UTC time.

What is the problem that needs to be solved? Provide size (in bytes) 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 your own automation with manual restore, and you can't programmatically know the actual filesize of .tar.gz file you'll be downloading for each snapshotId listed in GET /groups/{GROUP-ID}/clusters/{CLUSTER-NAME}/backup/snapshots Public API call until you actually download .tar.gz file for each snapshotId.

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.

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.

Show Snapshot progress (from provider snapshots) and possibly an ETA in Atlas UI

When performing a forensic analysis for the purposes of a restore, in order to determine the appropriate point in time when our data was last "sane", it would be awesome if we could start with a point-in-time restoration, and play the journal forward, e.g. performing a bisect on the data.

Allow to create a backup when we want, on every type of cluster (like we could do with mLab plans)

When I recently attempted to restore a db backup I got a cryptic error message stating "Error: Cluster Not Found"--which was extremely confusing considering that I pressed the restore button in the backup options. After some great tech support, I added my user as project owner and everything worked fine.

Please make the error message clearer in both the Restore and Download backup scenarios.

Two different ideas for this:
-When building a new cluster having the option to build it using a cloud backup snapshot for DR when a cluster is down

-Same idea to restore to a new cluster but from the restore target dropdown IE Restore to New cluster which opens the create a cluster workflow with the cloudbackup snapshot section populated

Provide a per cluster mechanism to shut off client access for restore operations.

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.

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.