Section 7.2. rsnapshot

7.2. rsnapshot

rsnapshot is an open-source backup and recovery tool based on Mike Rubel's original concept. It is designed to take a great idea and make it more accessible to users and more useful for larger environments. Under the hood, rsnapshot works in the same way as Mike Rubel's original scripts covered in the first part of the chapter. It uses hard links to conserve space and rsync to copy changes and break the hard links when necessary.

The major differences between rsnapshot and Mike Rubel's original script are that rsnapshot: ^[*]

^[*] Some of these differences no longer apply because Mike has continued to update his script. Specifically, the new version of Mike Rubel's script supports multiple trees and locking, and it also has a syslog support wrapper.

• Is written in Perl because Perl skills are readily available, and Perl can more easily parse a configuration file.

• Supports multiple levels of backup (daily, weekly, and monthly) from one script.

• Backs up multiple directory trees from multiple sources, with some optional fine-tuning of what rsync parameters are used.

• Supports locking so that two backups don't run at once.

• Has syslog support.

• Supports pre- and post-backup scripts, which are useful for things like taking dumps of databases.

7.2.1. Platform Support

rsnapshot is most at home on a Unix-like platform, such as Linux, FreeBSD, and Solaris, but it can be used to back up data on non-Unix platforms. rsnapshot itself needs to run somewhere that rsync can deal with hard links, which means somewhere like Unix. For these purposes, Mac OS X counts as a Unix platform, although there are some issues with Mac OS X's case-insensitive filesystem (HFS+) and resource forks. Thankfully, this is very rarely an issue. Resource forks are nowhere near as important in Mac OS X as they used to be in "classic" Mac OS. Please read the section on this topic in Chapter 3.

Classic Mac OS is not supported at all. While it may be possible to get an rsync server running on it and for rsnapshot to back it up, no changes will be made to rsnapshot to support this.

rsnapshot can back up Windows systems, but running the rsnapshot server on Windows is not supported because of the lack of hard-link support. Also, because permissions are so different in the Windows world compared with the Unix world, they will almost certainly not be backed up properly. Timestamps on files may not be backed up properly either, because Windows seems to store timestamps in the local timezone whereas Unix uses GMT. However, with these caveats, rsnapshot is being used successfully by many people to back up their Windows machines. To back up permissions, you can run a script before the backup to dump information about file permissions and users to a file that is then included in the snapshot. When you recover a file from backup, you then restore the correct permissions to files either by hand or with a script, referring to that file. Obviously, you should test this procedure before relying on it, to make sure you are recording enough data and that your script is correctly reading the file!

Finally, some obscure features of Unix filesystems aren't backed up because rsync doesn't support them: ACLs and filesystem extended attributes. These are rarely used, and you can use the same workaround described for Windows. No scripts of this nature are supplied with rsnapshot because there is so much variety from one platform to another (which is the same reason that rsync itself doesn't support them).

rdiff-backup often supports backing up ACLs.

7.2.2. When Not to Use rsnapshot

With even the slightest change to a file, rsnapshot puts a new copy of the file into your backup. This works well if you add a file, remove a file, or make large changes to a file. However, it does fall down if you either make small changes to a big file or are constantly changing a file. In those cases, you lose all the benefits of hard links. (rdiff-backup is covered later in the chapter.) Files where these sorts of change are common are logfiles and mboxes. Normally, these make up only a small proportion of the data on a machine, and so the amount of wasted space is actually quite small compared to the size of a backup. However, in the specific cases of mail servers and syslog servers, pretty much the only changes to files are of this sort. In those cases, we recommend using rdiff-backup instead.

7.2.3. Setting Up rsnapshot

rsnapshot packages are available for several Linux distributions and can be easily installed using the native package manager. If your distribution or OS doesn't have such a package available or if you want to be up to date with the most recent version, you can download a gzipped tar file from:

http://www.rsnapshot.org/downloads.html

To install that version, first uncompress the file:

 $ gzip -d rsnapshot-version.tar.gz | tar xvf -

Then change to the directory this command created:

$ cd rsnapshot-version

There is a file of instructions called INSTALL, but, in summary, for a fresh install you would normally need to issue these commands:

$ ./configure  $ su    (you will be asked for your password) # make install  # cp /etc/rsnapshot.conf.default /etc/rsnapshot.conf 

You then edit the file /etc/rsnapshot.conf to tell it where to put your backups, what to back up, and so on. There are copious instructions in the example config. Most users need to change only these settings:

backup

What to back up

snapshot_root

Where to put your backups

interval

When to back up

include and exclude

Which files rsync pays attention to

You can check your new configuration by typing:

$ rsnapshot configtest

If it all looks good, create cron jobs to run rsnapshot automatically. You can put them in root's cron file like this:

MAILTO=[e-mail] # so that I get emailed any errors 00 00 * * *    /usr/local/bin/rsnapshot daily    # every day at midnight 00 22 * * 6    /usr/local/bin/rsnapshot weekly   # every Saturday at 22:00 00 20 1 * *    /usr/local/bin/rsnapshot monthly  # the first of the month at 20:00

If you want to back up data from other machines, use ssh (which must be installed on both ends of the connection) and keys. There's a good description of how to do this securely here:

http://troy.jdmz.net/rsnapshot/

There's also a web frontend to the CVS repository here:

http://rsnapshot.cvs.sourceforge.net/rsnapshot/rsnapshot/

7.2.4. The rsnapshot Community

Open-source software lives or dies by its support. Thankfully, rsnapshot is well supported by an active mailing list that users are encouraged to subscribe to. It is used for reporting problems, discussing their fixes, announcing new releases, and so on. You can join the list or search the archives here:

https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

Many people post patches and add-ons to the list, some of which are committed to CVS by the small number of developers. If you've got good ideas and have posted good patches to the list, getting permission to commit to CVS is easy. Of course, everyone can look at and download the CVS repository anonymously.

rsnapshot is stable software. There are no plans to make major changes in how it works. The sort of changes you can expect to see are:

• More add-on scripts for reporting

• More database support scripts

• More configuration options

• Occasional bug fixes