Last month, I deployed a new version of one of our apps with an index that automatically expired documents after 2 hours.
In our testing environment, this index was great.
In production, it was chaos.
One of our collections was completely cleared out.
I went straight to my MongoDB Atlas account to restore from backup. The most recent backup was only 2 hours old, perfect. But there was an issue: Atlas only lets you restore the entire database (for point in time backups), not just a single collection. I only wanted to recover the affected collection to avoid overwriting healthy collections and not losing even more data.
At first, I tried downloading the backup and restoring it with mongorestore. No luck, it wouldn’t work for point in time backups. That’s when Ashley, a fantastic support rep from MongoDB Atlas, told me a trick:
“You can spin up MongoDB locally using the backup’s path as your data directory. That way, you can access your data directly.”
The Fix
I ran locally: mongod –dbpath=./path-to-backup-data …and it worked. I could now browse the backup as if it were running any other MongoDB instance.
From there, I had two options:
- Use mongodump and mongorestore to recover the collection.
- Or use a GUI tool like NoSQLBooster (which I use daily).
I went with NoSQLBooster, mainly because it was easier and I love NoSQLBooster. So I connected to my local backup database and also to the remote production database, then it was just copying and pasting the collection from local to remote.
After a couple of minutes, the operation finished. We only lost about 2 hours of data, far better than losing everything.
Key Takeaways
- Always know your backup options. Full restores are easy, but single-collection restores may require a workaround.
- You can run MongoDB locally from a point in time backup directory with: mongod –dbpath=./backupPath
- Tools like NoSQLBooster make copying collections much easier.
- Having up-to-date backups (and helpful support!) can turn a disaster into a small hiccup.
If I hadn’t had those Atlas backups, Ashley’s guidance, and NoSQLBooster, this story could have ended very differently.
