Can I backup a MongoDB database using Git? Specifically, could I include the mongo data directory in the github repository?

Question

I'm fairly new to Node + Mongo, and I'm trying to see if there's a way I can back up my database every time I make a new commit. Is this possible? I know how to backup using mongodump, but I would prefer to avoid having to do this each time I push to the server. If the data directory idea doesn't work, would it be possible to write a script which backs up to my node server repository and then does the push every time I run it?

I haven't been able to find anything relating git and mongo online, so I think I may be looking at this wrong/don't understand something. Any help would be greatly appreciated! Thanks!

Answer 1

Git hooks

If you want to have some action triggered on every commit, git does have a notion of "hooks" that allow you to invoke executable scripts.

For example, you could add a pre-commit or post-commit hook that runs a mongodump backup (wrapped in a shell script) before or after a successful commit as appropriate.

Data directory

Specifically, could I include the mongo data directory in the github repository?

I wouldn't include the data directory in your Git repository as the data files are locked for exclusive access when MongoDB is running. Copying files used by a running mongod instance may result in a corrupt or unusable "backup".

Binary data files will also significantly bloat your repository because they are (as at MongoDB 2.6) in an uncompressed binary format that includes some preallocated/unused storage. If you do want to store full data backups in version control, I would backup with mongodump and compress the resulting output directory with zip or tar+gzip before checking into version control.

Alternatives

Taking full database backups on every commit could eat up a lot of time & disk space. Depending on your concerns/requirements for having a backup of your database on every commit, some alternative approaches to consider are:

• If you are concerned about a rogue commit deleting or altering data, a MongoDB replica set deployment with a delayed secondary would allow you to keep an older view of data available (for example, delayed by two hours). This wouldn't replace a full backup strategy, but could be useful to keep your development workflow more agile while still providing some measure of data recovery on a bad commit.

• If you are more concerned about changes in the structure of your data or specific required data (rather than the full database), you could use a migration framework (e.g. mongo-migrate). Using explicit "migration scripts" to make changes to the structure of the data allows you to ensure that the data & structure matches what your code expects for a given checkout (associated .migrate scripts would be included with the code commit). This is also a helpful approach if you are working with a development team and want to try to ensure everyone has a similar data (without checking in full dumps).

• As @vmr mentioned, you can use a backup service like MMS (MongoDB Management Service) to take regular backups. The cloud version of MMS Backup can restore to a point-in-time within the last 24 hours.

Answer 2

All you need is MMS(Mongo monitoring service). It is a cloud based continuous backup service(plus lot of automation like on-demand restore,monitoring) offered by MongoDB. With MMS every single time you make a commit the DB gets backed up incrementally. It also possible to easily deploy and monitor standalone,replica-set or a sharded setup.

MMS is better compared to mongodump as it tends to do an incremental backup vs whole database backup.Writing a script which does mongodump on every commit will work but you will have to delete the old backup file every time you want to backup for a new commit. MMS cuts down on this devops overhead by manging all of this boiler-plate effort(writing scripts like mentioned) that goes into DBA's role.

Check-out this link for more info: MMS