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.

Agree that it should be possible to restore single DBs from a snapshot. Multiple DBs in a cluster are not unlikely (otherwise MongoDB Atlas get very expensive).
My understanding is that this was possible in the past and changed with Cloud Provider Backup (snapshots). I am investigating the possibility to use MongoDB Atlas for a big insurance company and consider this as a "Must have Feature".
Are there plans to make this very important feature available again?

Hi Thirumalaisamy,

We have some guidelines in the green box on this docs page that describe how to speed up a backup restore:
https://docs.atlas.mongodb.com/backup/cloud-backup/restore/#restore-your-snapshot-to-an-atlas-cluster

I am going to get this updated to be even more precise: For the fastest possible restore, restore to a cluster in the same Atlas Project, in the same region, with the exact same storage size as that of the cluster the Cloud Backup snapshot was taken from.

If you do this, you will have the fastest possible restore (irrespective of data size) -- from there you can very easily remove any collections/databases you don't need.

Cheers
-Andrew

Andrew,
we can do that. However, it will take more time to restore and grammatically syncing data may need process to get back to old state.
Hence, restoring a single db should be possibly restored from snap like restoring a cluster. This will give us
- faster restoring of db and applications accessing database will be back quicker
- Reduction in manual effort and faster recovery
- Possibility of easy of maintenance of cluster environment

Thiru

Hi Thirumalaisamy,

One option is to simply restore the full backup and then cull everything you don't need -- this can all be driven programmatically. Can you share whether this would work for you?

Cheers
-Andrew