Mongodb backup strategy

Hello,
I’ve been using mongodump-restore to have a backup of the db, and it works pretty well. However, I’ve noticed that as the db grows up, mongodump eats all server RAM swap. See the steps after each backup:


Mongo does not recommend dump-restore as a backup strategy for larger dbs (see mongodb official backup doc).

How do you usually do your backups? Is there any other better option? What would you recommend? Is there any option to keep using mongodump safely?

2 Likes

maybe try cold backups or snapshots

How would you do a cold backup? Just stopping mongod, running mongodump and restarting mongod?

It didn’t work… if I try to do a mongodump after shutting down mongod, it gives “Failed: error connecting to db server: no reachable servers”. Am I missing something?

@Andres.Aulasneo out of curiosity, did you ever find a decent solution?
and what size of ec2 instance are you using for the mongodb?

Hi @irishgordo! Thanks for asking!
No, I never found a decent solution. I am still using mongodump for backups and from time to time I reboot the instances to release the swap memory.
We still have mongo in the same instance as Open edX. They are t2.xlarge. We tried upgrading to x2large but it makes no sense. It only delays the problem to the next backup.
Moving Mongo out of the Open edX instance I think will only move the problem to the other instance, but will not fix it. What do you think?
This is why I was looking for a managed service for MongoDB. So far, going to Atlas looks like the most decent solution.

1 Like

Hey @Andres.Aulasneo thanks for the response! Sorry it took a few days to circle back to this, been heads down with the team on a lot of different things. Yeah I think if there’s any momentum within the EdX community to remove and refactor the MongoDB specific code chunks like $$ROOT and SetUnion things then DocumentDB with AWS would be a great managed solution.