As you may know, I recently set up subversion. As of this morning I was backing up my database with a daily cron job that sent mysqldump’s output to a file called database_[date].sql.bz2. That worked, but I’d rather not have to manage the files myself.
When I created the script to commit the newly created backup files, I intentionally removed the zipping step because I wanted to be able to use subversion’s diff feature, which would be useless if I commit binaries.
#!/bin/bash
# Dump the database and put it in a repository.
# Inspired by http://www.petersblog.org/node/959
# Written on Mon Oct 26 02:59:02 PST 2009
STORE_BACKUPS='/home/kj/backup'
WORKING_DIR='working_dir'
DATE=`/bin/date +%s`
FILE='server_'$DATE'.sql'
cd $STORE_BACKUPS
/usr/bin/mysqldump -u user -ppassword --skip-opt --comments=0 --all-databases>$FILE
# Must commit a whole directory even though
# we're only dealing with one file. The file name
# cannot change from day to day.
/bin/cp $FILE $WORKING_DIR/server.sql
cd $WORKING_DIR
/usr/bin/svn commit -m "daily backup; file saved as $FILE"
# I could delete $FILE now that $WORKING_DIR has
# been committed, but I like to have a backup
# backup in case the commit fails.
# If you want to live dangerously and assume
# everything went as planned, feel free to
# uncomment the following line to delete.
#/bin/rm $FILE
I believe this will fail if cron tries to commit the file a remote repository over ssh because the user is unable to address the password prompt. I’m told ssh is designed to not let you redirect input or otherwise script around the password prompt. A potential solution is having the server authenticate ssh users by key instead of password.
Oct 26 Edit: Minor bug fix. I haven’t tested it post-change. I don’t think I added any new bugs, but nobody ever thinks that, so use discretion before running this script.
