Various guides and experiments

Automatic Daily Backup of Files & Database to USB stick

On a development project I’m working on I was challenged with the task of setting up a daily backup of code and database until the project is completed and everything is moved to a production server that has a more proper backup system in place.

The customer, with physical access to the development server, suggested daily backups to a USB stick. He also suggested that the USB stick is switched with an identical one weekly with the other one being locked up in a safe place in case of fire or theft.

My first thought was to simply create a script that copies everything to a folder where I’ve mounted the USB stick, but it didn’t take long before I realised this would mean trouble when the USB sticks are switched once a week. I considered simply adding a check to see if it’s mounted and if not mount /dev/sdb1 in the correct folder, but after switching them once I noticed that the USB stick was actually assigned to /dev/sdc this time. Solution? udev. udev, an accompanying script to mount and finally the backup script.

What udev does is react to physical devices, identified by a set of rules, being connected or disconnected from the computer with things such as creating symlinks to the device and running scripts upon detection. It’s perfect for what I want to do – create a symlink (/dev/usbackup1) so it doesn’t matter what device name the stick gets assigned, sdb or sdc, and run a script to mount it where I want (/mnt/usbackup/)!

Here’s how the new udev rules file (/etc/udev/rules.d/10-usbackup.rules) look:

KERNEL=="sd*", SUBSYSTEMS=="scsi", ATTRS{vendor}=="Verbatim", SYMLINK+="usbackup%n", RUN+="/usr/local/bin/mount_usbackup"

The first three key-value pairs (the pairs are separated by comma) are for matching the device, in this case the kernel name for the device should match “sd*”, meaning sd and any letter, it should be in the “scsi” subsystem and finally the “vendor” attribute should match Verbatim (the maker of the USB stick in this case). There are plenty other attributes to match, such as partition size and model.

The remaining two key-value pairs are the ones that do all the magic – first of all to create a symlink to the device called /dev/usbackup. The “%n” is there to instruct udev to also create symlinks to the separate partitions (/dev/usbackup1 for the first partition etcetera). It then continues to run the script in /usr/local/bin/ called mount_usbackup. All the script does is mount the device where I want it to:

#! /bin/sh
mount /dev/usbackup1 /mnt/usbackup/

Finally! We can now be sure that we always have the right device mounted exactly where we want and won’t have to worry about any switching or manual mounting. What’s left? To actually create the backup, duh.

I chose to put my script in /etc/cron.daily to run it daily, but if you want to run it on a different schedule feel free to add a new entry to crontab or any other way you see fit. My script looks like this:

#! /bin/sh
tar -C /path/to/parent/ -cjf /mnt/usbackup/projectname/code/projectname_`date +'%F'`.tar.bz2 folder/
mysqldump -uuser -ppassword database | bzip2 > /mnt/usbackup/backup/projectname/db/projectname_`date +'%F'`.sql.bz2

The first line (after the shebang) first changes directory (“-C /path/to/parent/”) so we won’t have the full structure when we unpack and then creates a .tar.bz2 archive where we mounted the USB stick of the folder we want to create a backup of (“folder/” in this case).The second line dumps the MySQL database, pipes the output to bzip2 and puts it in a file on the USB stick. Both files are named projectname_<date in Y-m-d format>.ext.bz2 so we know what day the backup was taken.

It’s really quite simple and the bzip2 makes sure the backups doesn’t take up much space. In my case the whole thing, code and database, is just under half a megabyte after compression. As you can see it’s not an incremental backup, it makes a full copy every day, but as the size is so small (in my case at least) and it’ll be moved to a production server within two months I didn’t deem it necessary to make anything more complicated.

So yeah, that was my little backup endeavour.

Posted in Guides | Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *