Is it viable to handle MySQL backups with git?

Question

Today I had this really neat idea for backing up my database: put the dump file in a git repository, then commit on each dump so that I have both the most recent copy, but can easily roll back to any previous backup. I can also easily pull a copy of the repository on a regular basis to keep a copy on my own computer as a backup of the backups. It definitely sounds clever.

However, I'm aware that clever solutions sometimes have fundamental flaws. What sort of issues might I hit storing mysqldump diffs in git? Is it worth it? What do most people do in order to have multiple database backups on the server and keep redundant copies elsewhere?

Answer 1

Normally you don't keep every backup (or snapshot) forever. A git repository does keep every checkin you ever make. If you ever decide to prune old revisions (say month-old revisions down to once a week, year old to once a month, etc) you will have to do it with git filter-branch which will rewrite the entire history. Then git gc to remove the unwanted revisions.

Given that git's strengths are distributed version control and complex patch/branch workflows (neither of which apply to snapshots or backups) I'd consider using a different VCS with a more malleable history.

Answer 2

This approach sounds fine to me. I use Git for backing up my own important data.

Note that you are not storing diffs -- Git effectively stores snapshots of the directory state with each commit. You can generate the diff of two commits, but the actual storage mechanism has nothing to do with diff.