How do I do it?

Step 1:

First is to backup the database(s) to the filesystem in a common folder.

MySQL daily backups to a folder under /home/dbbackup for all DB’s using an easy to install backup shell script (automysqlbackup)

http://sourceforge.net/projects/automysqlbackup/

apt-get install automysqlbackup on debian based systems.

automysqlbackup gets run daily, and it automatically handles daily, weekly, monthly folders + rotation (no need to reinvent the wheel).

Step 2:

rsync my entire home folder system (which is where I store all my user specific data) to another server.

This also runs daily (usually in our early 2am – 4am period).

Step 3: Optional

I also do a weekly backup of the complete backup folder to a different server so I have some “history”.

To make it even safer, I also do a monthly offsite of the backups.

Our specific setup is that
I usually have a central backup server that I send data to (stuck on a spare drive on a less used web server).

Secondary and Tertiary backup backups are run from that.

Caveats – if your database is in iffy condition – eg latin1 encoding, with UTF-8 data, or similar, or crashed tables, the backup will not be 100%. automysqlbackup can be configured to email you on issues. encoding related ones will not be seen until a restore is attempted, but other issues will be.
I have successfully restored even with “corrupt” encoding data, whether it was latin1 -> utf8 or utf8 double encoding. Does need some handholding though if that needs to happen.

Having different snapshots of your data from different time periods (eg, daily, weekly, monthly) is important (and thats why I do it!).
The number of times clients have come back with “oh I deleted something 2 weeks ago”, and I’ve been able to restore it has meant that they’re happy.

That said, it does mean you need to use a whack of drives for backup purposes.

In our case we only have 6 servers, and web + mysql takes roughly 600GB (still fairly easy to stick onto a single drive though). They are scattered around different / regions also, so it can take a few days to complete an initial backup if I deploy a new backup server.
To avoid issues, I do a simple file test in my rsync cron script which gets deleted at the finish of the script. If the script gets run a second time it checks for the file, and aborts if found. This prevents multiple instances being run each day, which can cause issues for the initial long running backup.

Thanks for pointing this out!

So the short answer is that just using a VPS somewhere else works just fine. iBackup has a few extra advantages.

1) All they do is backups. They probably don’t have the sorts of issues that normal ISPs have to deal with (DDOS attacks, bad neighbor effects, etc). So their uptime is just great.

2) They are really super good about backing up whatever you have with them with their own backup systems. So your data is even *more* backed up. And more is better when it comes to backups IMO.

But honestly, sending backups off to another server in another data center is just fine too if it’s cost sensitive.

1) A lot of people these days are using VPS servers where you don’t have the ability to do snapshots. You can on some, you can’t on others.

2) Even if you’re just running bare metal boxes, you may not have a filesystem that supports snapshotting. Most people just run with defaults and that usually means ext3 these days (no snapshots).

But yes, it’s a great and easy option if it’s available. I was just shooting for something that would always work. Thanks for pointing it out!

Works well within Amazon EC2 as well.

I think, now I know why you wrote:
STUNNEL_PORT=`/bin/grep ‘accept’ /etc/stunnel/ibackup.conf | awk ‘{print $3}’`;

With $() command substitution you can use variables, so it make it more usable than backticks, for example:

#!/bin/sh
LSBIN=’/bin/ls’;
LSOUT=$($LSBIN -l);
echo $LSOUT;

So you can have variables for all the binaries.

And thanks for sharing the script, it’s a good starting point, but it isn’t too portable. For example:
STUNNEL_PORT=`/bin/grep ‘accept’ /etc/stunnel/ibackup.conf | awk ‘{print $3}’`;

What if the grep isn’t there :) Not really a problem, because you will find that out soon enough :D

And if you want to risk some security, you could use which to find out binary paths.

Juano already wrote about using stat command…

And if I remember correctly, it’s better to use $(ls foo) syntax than `ls foo`.

@Rob Morris
Configuration files and version information are sometimes crucial, a very good point!

- Configuration files – php.ini, httpd.conf, etc etc etc – these may have tons of tweaks added over several years. Recreating them right on a system rebuild can be hell.
- Version information – Often, the versions of libraries, server software, etc. are critical, and again, if you keep the config files, you need a version of the software that can use that config file.

Just a couple of notes from someone who has had to do full system rebuilds on more than one occasion. Great article, and good luck with those backups!

stat is your friend!

ie. stat -c %a $DOTIBACKUP will report the access permissions in octal.

Another suggestion would be using rsync over SSH with password-less auth using RSA keys.

Post is wrote in polish language, but You will understand script in bash :) My script dump all databases in diffrent files, so We can simply restore only one database (not all databases).

Great to get the info behind your script, and why its best to just go straight into the shell and back it up :)

Keep up the good work!

// Just a CDP Server satisfied customer

Any ideas of how to do it on a Windows machine?

@John, great tip on bzip – I’ve used it in the past for MySQL backup files and the compression is amazing compared to gzip.

Nice writeup. I find that I can never find a simple, effective backup script for MySQL when I’m starting a new project on a host without any kind of backup facilities, so it’s nice to have a point of reference!

I just wanted to note that in terms of worrying about locks, one way to avoid having to setup a slave for a busy DB is to store the DB data files on an XFS partition (http://en.wikipedia.org/wiki/Xfs). I used this once with a relatively small project when I didn’t want to deal with the headaches of MySQL replication, and it worked pretty well.

The trick is to take advantage of XFS’s support for snapshots. Basically, a snapshot of a drive can be taken at an exact INSTANT and survive for long enough for a dump to be taken from it. So instead of:

-locking all tables/databases
-dumping all data (which, as you said, can easily take 15+ seconds)
-unlocking all tables/databases

You can just:

-lock all tables/databases
-take an XFS snapshot (which usually takes < 2 seconds)
-unlock all tables/databases (freeing up the DB to handle requests)

Then, at your leisure,
-launch a secondary MySQL server using the snapshot's DB data files
-perform a dump from this secondary server
-stop the secondary server and delete the snapshot

This frees up the DB server almost immediately, ensures atomized data, and avoids the effort of configuring and maintaining a replication setup (which, given MySQL replication's tendency to short-circuit, can definitely be a plus).

Setting up XFS isn't usually too difficult, although it's much easier to do when you already have a free partition. Most newer Linux kernels have no problem supporting it, and as far as I know, it performs pretty admirably.

-Lou

I currently have a (mt) dv account with multiple sites that runs nightly at 3am, dumps the db’s, zips ‘em, and emails them to me. Quite nice, and like I said before, easy to setup.

$MYSQLDUMP –opt –databases $DB_NAMES | $BZIP2 -c > $DUMPDIR/$IBACKUP_DEST-$DATE.mysql.bz2

This means if you have a particularly large database backup you’re not hitting the disk with a large file and then freeing it up immediately. I’m also not about to advocated bzip over gzip but I’ve found better compression with bzip and my backups.