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

Hi Andrew,

this feature is also important for my company.

Indeed, we have several databases on each our clusters.

We can't use your procedure idea because we want to keep other databases on destination cluster.
We want to restore databases separately because other databases (on the same cluster) are used. Thus we can't delete them.

Another idea is the "deprecated" feature about "queryable backup" (here : https://docs.atlas.mongodb.com/backup/legacy-backup/restore-by-query/ ).
Why this feature is deprecated ?
Is possible to ask for its come back ?

Have you any other idea ?

thank you.
regards,
David.

This is a key feature for us.

We currently use the restore snapshot job to copy our data to our analytics cluster daily through the Atlas API. We want other databases in our analytics cluster to persist throughout these daily copies (hence why copying and deleting the data afterwards is not sufficient).

A manual dump and restore is currently our only option however it's significantly more expensive (cost and implementation time) as we must use a VM as a middleman for the dump and restore commands.

I'd add that if/when this feature gets implemented, the API should be extended so that this feature can be used in a automated pipeline.