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.