Imagine my surprise when I found out that the “Time Machine” backup in OS X Leopard is essentially using the same technique that Mike Rubel documented for use with Linux and BSD Unix almost a decade ago. Apple added a classy graphical interface… but Linux users can also have multi-generation backups that take minimal space, storing new versions of files as they change but keeping the old versions around.
Given two machines, main and backup, we will archive all the essentials files that make main unique — its configuration, web directories, users’ home directories and their saved mail — onto backup. Note that “backup” may be a machine in the same rack, or it could be located on the other side of the country.
While we’re going to use a second computer, you can also set it up using a second drive on the same computer as Apple’s “Time Machine” does.
1. Do a one-time set up of our directory structure on “backup” (using a disk that has enough room to hold everything, or distributing it between multiple disks if necessary):
# mkdir -p /DBbackup/main/root
# mkdir -p /DBbackup/main/etc
# mkdir -p /DBbackup/main/usr/share
# mkdir -p /DBbackup/main/opt
# mkdir -p /DBbackup/main/home
# mkdir -p /DBbackup/main/var/www
# mkdir -p /DBbackup/main/var/spool/mail
# mkdir -p /DBbackup/main/var/lib/mysql “mkdir -p” is a convenient shorthand way of making a subdirectory without laboriously making all the directories above it. “mkdir -p /foo/bar/baz” says “Don’t bother me if /foo or /foo/bar don’t already exist; if they don’t, then go ahead and make them, too!” I’m including the name of the machine we’re backing up, so one backup machine can be used to protect multiple others.
2. Set up ssh access with certificates from “main” to “backup” (There is a script to make that painless, called “lussh”). Verify that you can log on from main to backup without being prompted for a password.
The process we’re running needs to be root in order to preserve the ownership and access flags (”permissions”) of all the files we’re backing up. It also needs to log in as root on the remote machine, to be sure that it can READ everything. That’s a nasty situation, but ssh allows us to invalidate all passwords, and only allow access using certificates.
We can also add a few more speed bumps, such as running a separate instance of ssh on a non-standard port, e.g. 10022. You can then configure that instance to accept root logins, while you deny root logins on the default port. Then raise the bar a little higher with something like “fail2ban,” which will lock out the IP of script kiddies who try to brute-force the (nonexistent) root password on port 22, so they never get a chance to waste time hammering on port 10022.
To run such an alternate instance, you have to give the full path to the sshd executable when you start it up — /usr/local/sbin/sshd, not just sshd. And the syntax that rsync uses to tell ssh to run on an alternate port is a little odd; note the single quotes:
#rsync -e 'ssh -p 10022' ... 3. Here is our backup script, which runs on the backup box from root’s crontab.
#!/bin/sh
# MIRRORBACKUP - offsite backup using rsync over ssh
#----------------------------------------------------------------------------
# Presumes available root ssh login from "root@backup" to "root@main"
# using certificates to avoid the need for a login password, and that
# the backup directory tree has been prepared on "backup"
#----------------------------------------------------------------------------
# Part one - back up selected MySQL databases (e.g. mysql, database1) by
# running mysqlhotcopy on the machine that is to be backed up. The MySQL
# user password may be supplied below, or set in 'my.cnf' for a user with
# read-only privileges to all databases.
#----------------------------------------------------------------------------
ssh root@main "mysqlhotcopy --allowold -U root -P 'mysqlpass' mysql /DBbackup"
ssh root@main "mysqlhotcopy --allowold -U root -P 'mysqlpass' database1 /DBbackup"
#----------------------------------------------------------------------------
# Everything else runs on the backup box as root.
#----------------------------------------------------------------------------
rsync -e ssh -avz --delete root@main/DBBackup/ /DBBackup/main/var/lib/mysql
rsync -e ssh -avz --delete root@main:/etc/ /DBbackup/main/etc
rsync -e ssh -avz --delete root@main:/root/ /DBbackup/main/root
rsync -e ssh -avz --delete root@main:/usr/share/ /DBbackup/main/usr/share
#rsync -e ssh -avz --delete root@main:/opt/ /DBbackup/main/opt
rsync -e ssh -avz --delete root@main:/home/ /DBbackup/main/home
rsync -e ssh -avz --delete root@main:/var/spool/mail/ /DBbackup/mail/var/spool/mail
rsync -e ssh -avz --delete root@main:/var/www/ /DBbackup/main/var/www
#---------------------------------------------------------------------------
# MIRROR the BACKUP - keep three generations of /DBbackup
# (see *www.mikerubel.org/computers/rsync_snapshots/ )
# Rotate the prior two copies:
#---------------------------------------------------------------------------
if [ -d /DBbackup2 ]
then
mv /DBbackup2 /DBbackup3
fi
#
if [ -d /DBbackup1 ]
then
mv /DBbackup1 /DBbackup2
fi
#---------------------------------------------------------------------------
# Create hard-link-only copy of /DBbackup, the latest snapshot:
#---------------------------------------------------------------------------
cp -al /DBbackup /DBbackup1
#---------------------------------------------------------------------------
# END OF JOB
#---------------------------------------------------------------------------
# RESTORING THIS BACKUP
#---------------------------------------------------------------------------
# Note that we're not backing up the entire box. If the local machine
# dies utterly, you're not going to boot from a snapshot created this way,
# anyhow. However, once you have a reinstall done, which a typical service
# provider will do from a "canned" install, you can quickly restore your
# old configuration and your data.
#
# * Pick up the entire DBbackup directory tree:
# [backup~ ]# cd /DBbackup/main ; tar cfz main.tgz
# * Copy it to the replacement machine:
# [backup~ ]# scp /DBbackup/main/main.tgz root@newmain:/DBbackup
# * Log on to the replacement machine and unpack it in the root of
# the filesystem (the '/' directory):
# [backup~ ]# ssh root@newmain
# [newmain~]# cd / ; tar xvfz /DBbackup/main.tgz
#
# Note that you do NOT have to restore the whole backup; you can also
# pick individual files out of the DBbackup directory. That's yet
# another way in which it's nicer than having a single big "tarball."
#--------------------------------------------------------------------------- NOTES:
1. rsync snapshots
Mike Rubel’s use of rsync snapshots is a classic and you should read the original writeup to get the full flavor of it. Executive summary: Files that are identical will occupy the same space on disk; if a file changes, rsync will cleverly make a new copy of THAT file but leave the old version(s), so we have access to multiple generations of backup yet the total usage is barely more than one full copy (plus the changed files).
Drawbacks? /DBbackup and /DBbackup1, 2, and 3 must all be on the same filesystem for this hard-link trick to work. However, you can still use rsync as a utility to make (separate) copies across multiple disks.
2. A better MySQL backup strategy — replication AND mysqlhotcopy
mysqlhotcopy is a good tool, but it does involve locking the database for a few seconds. Also, it only gives us a periodic snapshot. If a MySQL database is business critical, it is much better (and still relatively easy) to set up a “slave” database, replicating changes from a “master.” See High Performance MySQL by Zawodny and Balling (oreilly.com).
Using a replication slave allows us to move the mysqlhotcopy task to the slave server, so there is no need to lock the master server even for an instant. The slave server can pause to “shoot” a backup and catch up with the master again almost instantly.
Source
It can be a life save when you've lost that precious document of yours or haf royally messed up your linux install!