The Problem with rsync

Rsync was designed to keep large sets of files synchronized between different systems or directories. As such, it does a pretty good job as a poor man's backup tool or helper tool. Typically I do local backups on the system with tar and mysqldump, putting the files into a directory with a date stamp (you'll see why later).To use rsync, simply create the file rsyncd.conf in /etc/:

uid = backups
gid = backups
use chroot = yes
[backups]
       path = /backups/
       read only = yes

Now enable it in inetd or xinetd. On the client side, you use a command such as rsync -a 10.1.2.3::backups/* /mybackups/ to copy the contents from the directory /backups/ on the remote server 10.1.2.3 to your local /mybackups/ directory. Now to make really sure nothing bad happens, you'll notice I didn't use the --delete option, which allows rsync to delete local files that are no longer present on the remote end. What could possibly go wrong? If a file gets deleted on my server, I'll still have a local copy. Right? Yes, but if a file gets zeroed by an attacker or from an error in a backup script (e.g., cat 0 > somefile), then the local copy will also get zeroed. In other words, say goodbye to your data. The solution is to make incremental backups, which is why I place my daily backups in a directory with that day's date as the name and then rsync that directory only:

rsync -a 10.1.2.3::backups/`date +%Y-%m-%d` /my-backups/

Anything in back ticks is executed by the shell and the output used. This means that in a worst case scenario I might lose today's backups, but I should never lose older backups because they are in a separate directory on my local server that I don't write to with rsync.

Do You Know Where Your Backups Are?

So you now have daily backups, copied off the server onto another hopefully secure machine. Or do you? All too often automated programs fail, IP addresses and hostnames change, the rsync configuration gets modified, the local disk partition for backups gets filled up, or who knows what happens. The final piece to the backup puzzle is automated notification of whether or not the backup was successful. The programs mentioned above (Amanda, Bacula, etc.) all support notification, but how can you build notification into your home-built rsync system? The solution to this is simple and elegant: Just add the following line to your backup script:

ls -la /my-backups/`date +%Y-%m-%d` | mail -s "daily backup report" your@email.address

This will do a directory listing of the new backup directory and pipe the output to the mail command, sending you an email with a listing of all the files and their sizes. In fact, you can go farther and list files within the archives with the tar -t command if you want to get fancy. In most cases, if you run rsync with the -v (verbose) option, you will receive output such as:

receiving file list ... done
2009-05-27/
2009-05-27/home.tar.bz2
2009-05-27/etc.tar.bz2

Please note that if you run commands from crontab, the output will automatically be emailed to the user that runs it.

Testing Your Backups

Some would say this final step is the most important when doing backups. First you need to take your backups and unpack them, load the tape onto a system, or do whatever you would actually do with them if you needed to restore data; otherwise, how can you be sure they work? Once you have done this, you can sleep soundly knowing that natural disasters (or ham-fingered system administrators) won't ruin your day.

The Author

Kurt Seifried is an Information Security Consultant specializing in Linux and networks since 1996. He often wonders how it is that technology works on a large scale but often fails on a small scale.