This is also a very important feature for us; was disappointed to see this regression in backup functionality at Atlas.

100% agree. This was a great feature of the legacy backup system. Now I have to create a new cluster (making sure to get all of the settings correct) then restore the backup to the new cluster. It's taken 20 minutes so far and I'm still waiting because I didn't get the size right so had to resize the new cluster. This is horrible when compared to the 10 seconds it use to take in order to be querying a backup. Really disappointed. New features that go backwards in functionality are not nice.

Please bring this feature back! It's one of the reasons we like MongoDB Atlas for the convenience of Queryable backups. We've used it several times in the past, it's disappointing it's no longer available.

Either a full queryable backup or a way to access/view contents of a backup to extract a database or collection would be really help us.

Thank you

Yeah this is extremely needed, we have a 100GB snapshot and our management wanted to view 1 collection from the snapshot from 3 months ago

Had to attempt to download a 100GB on my laptop, didn't work, kept timing out and ran out of disk space.. ended up having to spend money on a new cluster to restore just to view a single collection, which took almost a hour to restore

Even if no tunnel, we need a way so we can either download just a single collection or a better way to view the snapshots

Generally, data errors or loss, like inadvertently dropping a minor collection, should not require the complete restoration of the backup over the existing database. Doing so could have an even more adverse problem than rebuilding the missing document or collection. Instead, we should be able to read the snapshot and cherry-pick the desired data from either a replication set or a sharded cluster backup.

Like we can do in Cloud Manager Continuous Backup, We can query a snapshot. This download an .EXE file that will create a tunnel directly to the Backup Storage and allow us to retreive the document that we need (using localhost:27017), without restoring the whole backup, or having a 2nd database, giving access to the developer, ...

> Cloud Backup restores are extremely fast.

Unfortunately this isn't really true. Restorations for my ~8GB database (which is pretty small) take about 15 minutes to restore, which, in addition to the 15 minutes to provision a new cluster, etc., means waiting around 30-45 minutes just to make a single query, only to realize you need to go back one more day in your snapshots and try again, waiting another 15-30 minutes.

It's also expensive. Every backup restoration gets charged "data transfer fees", which add up fast if you need to dig through more than one snapshot, especially as the database grows. It's just a *little bit* questionable to ask your customers to use an obnoxious, slow, workaround for a feature that should be standard, and then charge them for it.

I really hope the Devs actually work on this, especially since it *used* to work in the legacy backups!

I am happy to hear that you guys are bringing back queryable snapshots! That was an awesome feature in Legacy Backups for quickly retrieving deleted or corrupted documents or examining the state of data at any point in time.

Hello,

We are planning on building a new version of queryable for Cloud Backup but not with a tunnel. In the meantime, I would suggest provisioning a new cluster, restoring the backup, do what you need, and then tear it down. Cloud Backup restores are extremely fast. This would be the best way for the time being.