2

I have a Ubuntu server hosting a PHP5 / MySQL webapp. I also have another server (offsite) with a directory just for backups of my webapp server. Currently, I have a simple cron job which performs the following:

  1. Copies /var/www to local backup directory. Command: cp -ua /var/www /backup/www
  2. Performs mysqldump of information_schema and my app's database and copies those files to the local backup directory.
  3. Mounts the backup server as an sshfs volume.
  4. Copies all files from the local backup directory to the sshfs volume.

Questions:

  1. Is this an efficient solution or would a dedicated backup program work better/faster?
  2. Am I covering everything I need? For example: are there configuration files that I should backup too (PHP, Apache2, MySQL)?
  3. If there is a dedicated backup program that would serve my needs better, which would you recommend?

Thanks for any advice

3 Answers 3

4

I'd recommend something that can do incremental backups, because that way you can go back to files that were changed several days ago. We use dirvish for this (it's available from the ubuntu repos) - basically it's a wrapper for rsync written in perl that makes it easier to setup a system to run regular incremental backups, and then expire them based on given rules.

On our system we keep backups for 7 days, but keep the first backup of the week for 1 month, and the first backup of the month for one year, so usually you can find files that were modified and deleted some time ago. For things that are small, but important, we have much longer expiry times.

As for what you should backup, imo if you have the space back up everything unless you're sure you don't need to back up. With incremental rsync backups you're only copying over the files that have changed since the last backup - I'd rather have an extra 3gb of static data belonging to the operating system on my backup drive than find it was missing one important file when I needed to recover it.

At a minimum I'd backup the entire contents of /etc/, and most of /var depending on what stuff was running on the server.

If your mysql database is fairly small then your current approach is probably acceptable, but since you need to lock the database to generate the dump this isn't practical on large databases. Because of this lots of people run a slave mysql server, which is just a read only copy of the main one on the backup server, and use this to generate backups.

The mysql documentation on how to do this is fairly good, I worked through it the first time in an evening, without much previous mysql experience.

We have our slave mysql server tied into dirvish, so each day it generates a dump of each individual database, as well as an entire copy of /var/lib/mysql (it's stops the mysql server before doing this)

2
  • Thank you. Very helpful information. The size of my MySQL backup is currently ~80MB, but the webapp isn't seeing real world use yet, so it's hard to tell how big it will get. I'll look into setting up a MySQL slave server before it gets too much bigger. I'll check out dirvish too. Jul 24, 2009 at 3:24
  • We use backuppc, which is very similar in design to dirvish, but has a very nice web user interface. If you're going to use a slave mysql database for backups, stop the replication before you start the backups, so you get a consistent database dump. This is probably more important if you have data split across more than one database. We don't both doing a backup of the mysql data files, only the SQL from mysqldump. Jul 24, 2009 at 7:55
2

See convenient & easy way backing up mySQL & SVN on Ubuntu machine, which pretty much sums up what you need.

In short;

  • There are a few standard packages; I've had good experiences with backupninja and rdiff-backup. Look at what's available, what suits your needs and pick that.
  • You should keep a backup of /etc/ (server configuration), all your web stuff, RCS-data, database. I usually copy the home directories as well, because I usually have a bunch of nice small scripts that really don't fit anywhere else and if I have to restore a server it is really nice to have a 'known' setup of the shell, preferred editor etc.
  • While you do above, plan - at least in your head - "what do I do when things go bad?" (i.e. know what's where in your backup and how to restore from it.)
1

i have my servers backup everything i needed backed up to a tar, then it gets copied to a external backup. the script will also delete the backups from 7 days back. i forgot where i found it, but i didnt write it.

!/bin/bash
# fecha has a formated date
fecha=`date +"%d-%m-%Y"`
# Backup and gzip the directory
sudo tar cvzpf /backups/backup-$fecha.tgz --same-owner  --exclude="/export/*" --exclude="/backups/*" --exclude="/home/error.log" --exclude="/proc/*" --exclude="/media/*" --exclude="/dev/*" --exclude="/mnt/*" --exclude="/sys/*" --exclude="/tmp/*" / 2>/home/error.log
# Rotate the logs, delete older than 7 days
find /backups/ -mtime +7 -exec rm {} \;

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .