1. Copy files to a temporary directory.
2. Dump the MySQL data into a file in that directory.
3. Tarball it up.
4. Scp that file to another server that I run.

At the time, I did this because it was the simplest thing that could possibly work.  It didn’t depend on any external facility other than mysqldump, tar, and scp.

Well, running that script on a nightly cron filled up my disk allocation on that remote server a couple times, so I got clever with the backup organization so I could quickly remove old backups while keeping sparser (monthly) backups for longer.  This only helped a little, because I was still nervous about deleting backups because I didn’t know what they contained.

I also have been using git more and more recently and I liked the idea of version control that can go in any direction.  So, in the spare bits of time I’ve had in the past few weeks, I wrote git_backup.pl.  It takes a git repository and does the following:

• git add <any new or modified files>
• git rm <any deleted files>
• git commit
• git push backup

Now, when the backup is run, only the small changes are sent to the remote server and I can look at the differences by examining the git log.

There are options for dumping database tables, changing the commit message and the remote that gets the push.  Running “git_backup.pl –man” will show all the options.

The source is (of course) in a git repo: http://git.endot.org/git_backup.git

The tree and history can be browsed at http://git.endot.org/.