agree, feature (specify specific database or collection) it was requested by our customer to optimize cost and time to take/restore backup.

Current process of restoring a full cluster snapshot requires a lot of time (which is critical during DRP) and resources. It also very brittle due to a number of manual steps required. Having a possibility to restore specific collections would simplify the process significantly.

This feature would really help smoothen out DRP procedures. Upvoted!

This would be a great feature to have.

Upvoting the request, received the feedback from Customer that this feature would be very useful

This is important feature request to have backup at collection level. Everybody does not need snapshot of the entire database which could be of very large size and If I want to restore specific collection then there is a long process of getting rid of all non-required collections.

I second this request. Due to the backup being a full cluster snapshot, including oplog and other internals, its size is much larger than our actual data. Being able to just backup the contents of one or more databases would lead to smaller backups that are likely also faster to restore.

I agree, we need to be able to restore individual databases from a cluster snapshot, instead of everything.

upvoting this request.

At this time the Cloud Backup snapshot restore completely wipes the destination. I would like to have a function to restore only a specific collection.

It is efficient and reduces overhead to store many small databases on the same cluster. However currently we also sacrifice RTO (and the ability to refresh dev/qa from backup) because we are unable to restore individual databases. Having the ability to restore an individual database from snapshot would allow us to more easily support small databases.

Hello Team,

This is Raja Selvam,

I would like to get more details on Clod backup.

Lets say suppose i would like to get yesterday's backup from one of the collection.

I do not want to restore the backup into another new cluster.
I do not want to download the backup since my Data will be around 1 TB, Incase if I go for download option this will take 1 day.

This solution also not working since we have to load the data to s3.
https://docs.atlas.mongodb.com/backup/cloud-backup/export/

Can we have option for cloud backup like legacy backup in feature. We ate tottaly blocked because of this dis adv in atlas. Even for single doc data validation we are creating a M60 cluster with 1 TB data which will take 1 to 2 hours near also cost effective.

Please provide the best solution for the same

Sample ticket : https://support.mongodb.com/case/00900476

Even with the fast attach, being able to restore specific DBs and collections from a snapshot to an existing cluster would simplify surgical restore operations.

This is really a sore spot for Atlas.
Having to restore a full cluster, to get to a single database or collection is slow and cumbersome.

Would love for individual database to be restored for backup.

I would upvote this ability as well. This is simply requesting feature-parity between Cloud Backup and the (now deprecated) Legacy Backup.
Thank you,
PH

I would also like to suggest restoring the "queryable backup" functionality. We often use this to help customers that accidentally delete data, and diagnose issues by looking at the past state of the database. The removal of legacy backups in 4.2+ is what has kept us from upgrading beyond 4.0.

Hello Mongo-Team,

we would like this to be possible even at the collection level.

We have several databases for different microservices on a cluster and would like to be able to restore a single collection if it has been corrupted.

The process via dump/restore is not practical for us because: It requires too much storage cache and and the data transfers over the network take too long.

Kind regards,
Michael.

Upvoted, we think "Queryable backups" is really needed here.
Common disaster where an individual mess up with a small subset of data (ie, an update query with the wrong filter conditions) is really painful to recover right now (we need to locally dump GB of data first, in order to cherry-pick and restore the impacted documents).

Hi,

People do delte collections by mistake. We should never need to go through all these painful procedure expecially when the production is impacted. This is most basic feature of the backup. Please do it at the earliest.

Amrish.

Agreed, this should receive priority consideration and is a basic function for multi-tenancy; not only for Atlas, but on-prem as well. The queryable backup functionality has limitations, and even then requires a dump / restore to pull a specific database. More in-line with enterprise functionality would be to perform a direct restore for just a specific database