The backup archives can be very large, and if my download is interrupted, without Accept-Range, it is not resumable. A length header is also missing, so the downloader doesn't know the size of the archive.

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

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)

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.

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.

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.

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

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.

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.

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.

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.

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)

mongodb doesn't have 7 years backup retention for yearly backup. Please add feature to take yearly backup and enable backup retention for years

We would like to schedule our monthly backup and 1st Sunday of every month. Currently, this option is not available via the Atlas Console. It gives options like 1st, 2nd, 3rd, 4th...etc of every month but not a specific day like Sunday or Monday. Please consider adding this option as it will be ideal for us to take our monthly backup on a Sunday when the database is not busy.

hourly backup retention. Why minimum a day, so 24 backups stored? For big databases, this is an amount of data and money

This is an important security requirement. Right now Cloud backups only create backups in the same region as the data replica itself. It would be a nice improvement to support backups in different regions in the same country.