Let’s back up the directory /home. The example directory has three files:

$ echo "original myfile" >/home/myfile.txt
$ echo "original myotherfile" >/home/myotherfile.txt
$ echo "original mythirdfile" >/home/mythirdfile.txt
$ ls -l /home
total 3
-rw-r--r--  1 cpreston mkgroup-l-d 16 Jul  8 19:35 myfile.txt
-rw-r--r--  1 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  1 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

Now let’s create a copy of /home in /backups/home.

$ cp -a /home /backups/home.0
$ ls -l /backups/home.0
total 3
-rw-r--r--  1 cpreston mkgroup-l-d 16 Jul  8 19:35 myfile.txt
-rw-r--r--  1 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  1 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

$ du -sb /backups
58      /backups

Note that each file shows a 1 in the links column, there is one copy of the /home directory in /backups and it contains the same files as /home, and the entire /backups directory takes up 58 bytes, which is the same as the number of bytes in all three files. Now let’s create a second copy using hard links:

$ cp -al /backups/home.0 /backups/home.1
$ ls -l /backups/*
/backups/home.0:
total 3
-rw-r--r--  2 cpreston mkgroup-l-d 16 Jul  8 19:35 myfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

/backups/home.1:
total 3
-rw-r--r--  2 cpreston mkgroup-l-d 16 Jul  8 19:35 myfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

$ du -sb /backups
58      /backups

Now you can see that there are two copies of /home in /backups, each contains the same files as /home, and they still take up only 58 bytes because we used hard links. You should also note that the links column in the ls -l listing now contains a 2. Now let’s change a file in the source directory:

$ ls -l /home/myfile.txt
-rw-r--r--  1 cpreston mkgroup-l-d 16 Jul  8 19:35 /home/myfile.txt
$ echo "LET'S CHANGE MYFILE" >/home/myfile.txt
$ ls -l /home/myfile.txt
-rw-r--r--  1 cpreston mkgroup-l-d 20 Jul  8 19:41 /home/myfile.txt

Please note that the size and modification time of myfile.txt changed. Now it’s time to make a backup. The process we described earlier would notice that /home/myfile.txt has changed and that it should be removed from the backup directory and copied from the source. So let’s do that:

$ rm /backups/home.0/myfile.txt
$ cp -a /home/myfile.txt /backups/home.0/myfile.txt
$ ls -l /backups/*
/backups/home.0:
total 3
-rw-r--r--  1 cpreston mkgroup-l-d 20 Jul  8 19:41 myfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

/backups/home.1:
total 3
-rw-r--r--  1 cpreston mkgroup-l-d 16 Jul  8 19:35 myfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

$ du –sb /backups
78

Now you can see that myfile.txt in /backups/home.1 has only one link (because we removed the second link in /backups/home.0), but it still has the same size and modification date as before. You can also see that /backups/home.0 now contains the new version of myfile.txt. And, perhaps most importantly, the size of /backups is now the original size (58 bytes) plus the size of the new version of myfile.txt (20 bytes), for a total of 78 bytes. Now let’s get ready to make another backup. First, we have to create the older versions by moving directories around:

$ mv /backups/home.1 /backups/home.2
$mv /backups/home.0 /backups/home.1

Then we need to create the new previous version using cp -al:

$ cp -al /backups/home.1 /backups/home.0
$ ls -l /backups/*
/backups/home.0:
total 3
-rw-r--r--  2 cpreston mkgroup-l-d 20 Jul  8 19:41 myfile.txt
-rw-r--r--  3 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  3 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

/backups/home.1:
total 3
-rw-r--r--  2 cpreston mkgroup-l-d 20 Jul  8 19:41 myfile.txt
-rw-r--r--  3 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  3 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

/backups/home.2:
total 3
-rw-r--r--  1 cpreston mkgroup-l-d 16 Jul  8 19:35 myfile.txt
-rw-r--r--  3 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  3 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

$ du -sb /backups
78      /backups

Now we have /backups/home.2, which contains the oldest version, and /backups/home.1 and /backups/home.0, which both contain the current backup. Please note that the size of /backups hasn’t changed since the last time we looked at it; it’s still 78 bytes. Let’s change another file and back it up:

$ echo "LET'S CHANGE MYOTHERFILE" >/home/myotherfile.txt
$ rm /backups/home.0/myotherfile.txt
$ cp -a /home/myotherfile.txt /backups/home.0/myotherfile.txt
$ ls -l /backups/*
/backups/home.0:
total 3
-rw-r--r--  2 cpreston mkgroup-l-d 20 Jul  8 19:41 myfile.txt
-rw-r--r--  1 cpreston mkgroup-l-d 25 Jul  8 19:45 myotherfile.txt
-rw-r--r--  3 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

/backups/home.1:
total 3
-rw-r--r--  2 cpreston mkgroup-l-d 20 Jul  8 19:41 myfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  3 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

/backups/home.2:
total 3
-rw-r--r--  1 cpreston mkgroup-l-d 16 Jul  8 19:35 myfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  3 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

$ du -sb /backups
103     /backups

You can see that /backups/home.0 now contains a different version of myotherfile.txt than what is in the other directories, and that the size of /backups has changed from 78 to 103, which is a difference of 25—the size of the new version of myotherfile.txt. Let’s prepare for one more backup:

$ mv /backups/home.2 /backups/home.3
$ mv /backups/home.1 /backups/home.2
$ mv /backups/home.0 /backups/home.1
$cp -al /backups/home.1 /backups/home.0

Now we’ll change one final file and back it up:

$ echo "NOW LET'S CHANGE MYTHIRDFILE" >/home/mythirdfile.txt
$ rm /backups/home.0/mythirdfile.txt
$ cp -a /home/mythirdfile.txt /backups/home.0/mythirdfile.txt
$ ls -l /backups/*
/backups/home.0:
total 3
-rw-r--r--  3 cpreston mkgroup-l-d 20 Jul  8 19:41 myfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 25 Jul  8 19:45 myotherfile.txt
-rw-r--r--  1 cpreston mkgroup-l-d 29 Jul  8 19:51 mythirdfile.txt

/backups/home.1:
total 3
-rw-r--r--  3 cpreston mkgroup-l-d 20 Jul  8 19:41 myfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 25 Jul  8 19:45 myotherfile.txt
-rw-r--r--  3 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

/backups/home.2:
total 3
-rw-r--r--  3 cpreston mkgroup-l-d 20 Jul  8 19:41 myfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  3 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

/backups/home.3:
total 3
-rw-r--r--  1 cpreston mkgroup-l-d 16 Jul  8 19:35 myfile.txt
-rw-r--r--  2 cpreston mkgroup-l-d 21 Jul  8 19:35 myotherfile.txt
-rw-r--r--  3 cpreston mkgroup-l-d 21 Jul  8 19:35 mythirdfile.txt

$ du –sb /backups
132

Again, the total size of /backups has changed from 103 bytes to 132, a difference of 29 bytes, which is the size of the new version of mythirdfile.txt.

The proof is in the restore, right? Let’s look at all versions of all files by running the cat command against them:

$ cat /backups/home.3/*
original myfile
original myotherfile
original mythirdfile
$ cat /backups/home.2/*
LET'S CHANGE MYFILE
original myotherfile
original mythirdfile
$ cat /backups/home.1/*
LET'S CHANGE MYFILE
LET'S CHANGE MYOTHERFILE
original mythirdfile
$ cat /backups/home.0/*
LET'S CHANGE MYFILE
LET'S CHANGE MYOTHERFILE
NOW LET'S CHANGE MYTHIRDFILE

You can see that the oldest version (/backups/home.3) has the original version of every file, the next newest directory has the modified myfile.txt, the next newest version has that file and the modified myotherfile.txt, and the most recent version has all of the changed versions of every file. Isn’t it a thing of beauty?

The example, while it works, is simple to understand but kind of clunky to implement. Some of the steps are rather manual, including creating the hard-linked directory, identifying the new files, removing the files you’re about to overwrite, and then sending the new files. Finally, our manual example does not deal with files that have been deleted from the original; they would remain in the backup. What if you had a command that could do all that in one step? You do! It’s called rsync.

The rsync utility is a very well-known piece of GPL’d software, written originally by Andrew Tridgell and Paul Mackerras. If you have a common Unix variant, you probably already have it installed; if not, you can install a precompiled package for your system or download the source code from rsync.samba.org and build it yourself. rsync’s specialty is efficiently synchronizing file trees across a network, but it works well on a single machine, too. Here is an example to illustrate basic operation.

Suppose you have a directory called <source>/ whose contents you wish to copy into another directory called <destination>/. If you have GNU cp, you can make the copy like this:

$ cp -a source/. destination/ 

The archive flag (-a) causes cp to descend recursively through the file tree and to preserve file metadata, such as ownerships, permissions, and timestamps. The preceding command first creates the destination directory if necessary.

However, if you make regular backups from <source>/ to <destination>/, running cp every time is not efficient because even files that have not changed (which is most of them) must be copied every time. Also, you would have to periodically delete <destination>/ and start fresh, or backups of files that have been deleted from <source>/ will begin to accumulate.

Fortunately, where cp falls short at copying mostly unchanged filesystems, rsync excels. The rsync command works similarly to cp but uses a very clever algorithm that copies only changes. The equivalent rsync command would be:

$ rsync -a source/. destination/ 

You’ll probably want to add the --delete flag, which, in addition to copying new changes, also deletes any files in <destination>/ that are absent (because they have presumably been deleted) from <source>/. You can also add the verbose flag (-v) to get detailed information about the transfer. The following command is a good way to regularly synchronize <source>/ to <destination>/:

$ rsync -av --delete source/. destination/ 

rsync is good for local file synchronization, but where it really stands out is for synchronizing files over a network. rsync’s unique ability to copy only changes makes it very fast, and it can operate transparently over an ssh connection. To rsync from /<source>/ on the remote computer example.oreilly.com to the local directory /<destination>/ over ssh, you can use the command:

$ rsync -av --delete username@example.oreilly.com:/source/. /destination/ 

That was pull mode. rsync works just as well in push mode from a local /<source>/ to a remote /<destination>/:

$ rsync -av --delete /source/. username@example.oreilly.com:/destination/ 

As a final note, rsync provides a variety of --include and --exclude options that allow for fine-grained control over which parts of the source directory to copy. If you wish to exclude certain files from the backup—for example, any file ending in .bak or certain subdirectories—they may be helpful to you. For details and examples, see the rsync manpage.

Hard links are an important Unix concept to understand if you’re going to use this technique. Every object in a Unix filesystem, which includes every directory, symbolic link, named pipe, and device node, is identified by a unique positive integer known as an inode number. An inode keeps track of such mundane details as what kind of object it is, where its data lives, when it was last updated, and who has permission to access it. If you use ls to list files, you can see inode numbers by adding the -i flag:

$ ls -i foo 
409736 foo

What does foo consist of? It consists of an inode (specifically, inode number 409736) and some data. Also—and this is the critical part—there is now a record of the new inode in the directory where foo resides. It now lists the name foo next to the number 409736. That last part, the entry of a name and inode number in the parent directory, constitutes a hard link.

Most ordinary files are referenced by only one hard link, but it is possible for an inode to be referenced more than once. Inodes also keep a count of the number of hard links pointing to them. The ls –l command has a column showing you how many links a given file has. (The number to the left of the file owner’s user ID is the number of hard links—one in the following example.)

$ ls -l foo
-rw-r--r--  1 cpreston mkgroup-l-d 16 Jul  8 19:35 foo

To make a second link to a file within a filesystem, use the ln command. For example:

$ ln foo bar 
$ ls -i foo bar
409736 foo 
409736 bar

Now the names foo and bar refer to the same file. If you edit foo, you are simultaneously editing bar, and vice versa. If you change the permissions or ownership on one, you’ve changed them on the other, too. There is no way to tell which name came first. They are equivalent.

When you remove a file, all you’re removing is a link to that inode; this is called unlinking. An inode is not actually released until the number of links to it drops to zero. (Even then, the inode is freed only when the last process has finished using it, which is why you can remove the executable of a running program.) For example, ls -l now tells you that foo has two links. If you remove bar, only one remains:

$ ls -l foo
-rw-r--r--  2 cpreston mkgroup-l-d 16 Jul  8 19:35 foo
$ rm bar
$ ls -l foo
-rw-r--r--  1 cpreston mkgroup-l-d 16 Jul  8 19:35 foo

The situation would have been the same if you’d removed foo and run ls -l on bar instead. If you now remove foo, the link count drops to zero, and the operating system releases inode number 409736.

Here is a summary of some of the important properties of hard links. If foo and bar are hard links to the same inode:

In the previous section, you learned that ln foo bar creates a second hard link called bar to the inode of file foo. In many respects, bar looks like a copy of foo created at the same time. The differences become relevant only when you try to change one of them, examine inode numbers, or check disk space. In other words, as long as in-place changes are prohibited, the outcomes of cp foo bar and ln foo bar are virtually indistinguishable to users. The latter, however, does not use additional disk space.

Suppose you wanted to make regular backups of a directory called <source>/. You might make the first backup, a full copy, using rsync:

$ rsync -av --delete source/. backup.0/

To make the second backup, you could simply make another full copy, like so:

$ mv backup.0 backup.1 
$ rsync -av --deletesource/. backup.0/ 

That would be inefficient if only a few of the files in <source>/ changed in the interim. Therefore, you create a second copy of backup.0 to use as a destination (since you’re using hard links, it won’t take up any more space). You can use two different techniques to make backups in this way. The first is a bit easier to understand, and it’s what we used in the example. The second streamlines things a bit, doing everything in one command.

GNU cp provides a flag, -l, to make hard-link copies rather than regular copies. It can even be invoked recursively on directories:

$ mv backup.0 backup.1 
$ cp -al backup.1/. backup.0/ 
$ rsync -av --delete source/. backup.0/

Putting cp -al in between the two backup commands creates a hard-linked copy of the most recent backup. You then rsync new changes from <source>/ to the backup.0. rsync ignores files that have not changed, so it leaves the links of unchanged files intact. When it needs to change a file, it unlinks the original first, so its partner is unaffected. As mentioned before, the --delete flag also deletes any files in the destination that are no longer present in the source (which only unlinks them in the current backup directory).

rsync is now taking care of a lot. It decides which files to copy, unlinks them from the destination, copies the changed files, and deletes any files it needs to. Now let’s take a look at how it can handle the hard links as well. rsync now provides a new option, --link-dest, that will do this for you, even when only metadata has changed. Rather than running separate cp -al and rsync stages, the --link-dest flag instructs rsync to do the whole job, copying changes into the new directory, and making hard links where possible for unchanged files. It is significantly faster, too.

$ mv backup.0 backup.1 
$rsync -av --delete --link-dest=../home.0 /home/. /backups/home/ 

rsync -av --delete --link-dest=../home.0 /home/. /backups/home.inprogress/
[ -d /backups/home.2 ] && rm -rf /backups/home.2
[ -d /backups/home.1 ] && mv /backups/home.1 /backups/home.2
[ -d /backups/home.0 ] && mv /backups/home.0 /backups/home.1
[ -d /backups/home.inprogress ] && mv /backups/home.inprogress /backups/home.0
touch backups/home.0

Because backups created this way are just conventional Unix filesystems, there are as many options for restoring them as there are ways to copy files. If your backups are stored locally (as on a removable hard disk) or accessible over a network filesystem such as NFS, you can simply cp files from the backups to /home. Or better yet, rsync them back:

$ rsync -av --delete /backups/home.0/. /home/ 

Be careful with that --delete flag when restoring: make sure you really mean it!

If the backups are stored remotely on a machine you can access by ssh, you can use scp or rsync rather than ssh. Other simple arrangements are also possible, such as placing the directories somewhere that is accessible to a web server.

Here are a few other things to consider if you’re going to use the rsync method for creating backups.

$ find /backups/home.1 -type f -links 1 -print 

$ du -hc 'find /backups/home.1 -type f -links 1 -print' | tail -n 1 

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.

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).

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.

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:

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:

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:

[email protected] # 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:

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

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:

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:

Here are some advantages of using rdiff-backup instead of an rsync script or rsnapshot:

Let’s be honest. rdiff-backup has some disadvantages, too:

Here’s a basic, but complete, example of how to use rdiff-backup to back up and restore a directory. Suppose the directory to be backed up is called <source>, and we want our archive directory to be called <destination>:

$ rdiff-backup source destination

This command backs up the <source> directory into <destination>. If you look into <destination>, you’ll see that it is just like <source> but contains a directory called <destination>/rdiff-backup-data where the metadata and deltas are stored. The rdiff-backup-data directory is laid out in a fairly straightforward way—all information is either in (possibly gzipped) text files or in deltas readable with the rdiff utility—but we don’t have the space to go into the data format here.

The first time you run this command, it creates the <destination> and <destination>/rdiff-backup-data directories. On subsequent runs, it sees that <destination> exists and makes an incremental backup instead. For daily backup usage, no special switches are necessary.

Suppose you accidentally delete the file <source>/foobar and want to restore it from backups. Both of these commands do that:

$ cp -a destination/foobar source
$ rdiff-backup -r now destination/foobarsource

The first command works because <destination>/foobar is a mirror of <source>/foobar, so you can use cp or any other utility to restore. The second command contains the - r switch, which tells rdiff-backup to enter restore mode, and restore the specified file at the given time. In the example, now is specified, meaning restore the most recent version of the file. rdiff-backup accepts a large variety of time formats.

Now suppose you realize you deleted the important file <source>/foobar a week ago and want to restore. You can’t use cp to restore because the file is no longer present in <destination> in its original form (in this case it’s gzipped in the <destination>/rdiff-backup-data directory). However the -r syntax still works, except you tell it 7D for seven days:

$ rdiff-backup -r 7D destination/foobarsource

Finally, suppose that the <destination> directory is getting too big, and you need to delete older backups to save disk space. This command deletes backup information more than one year old:

$ rdiff-backup –-remove-older-than 1Ydestination

Just like rsync, rdiff-backup allows the source or destination directory (or both) to be on a remote computer. For example, to back up the local directory <source> to the <destination> directory on the computer host.net, use the command:

$ rdiff-backup sourceuser@host.net::destination

This works as long as rdiff-backup is installed on both computers, and host.net can receive ssh connections. The earlier commands also work if [email protected]::<destination> is substituted for <destination>.

Although rdiff-backup was originally developed under Linux for Unix-style systems, newer versions have features that are useful to Windows and Mac users. For instance, rdiff-backup can back up case-sensitive filesystems and files whose names contain colons (:) to Windows filesystems. Also, rdiff-backup supports Mac resource forks and Finder information, and is easy to install on Mac OS X because it is included in the Fink distribution. Unfortunately, rdiff-backup is a bit trickier to install natively under Windows; currently, cygwin is probably the easiest way.

Future development of rdiff-backup may consist mostly of making sure that the newer features like full Mac OS X support are as stable as the core Unix support, and adding support for new filesystem features as they emerge. For more information on rdiff-backup, including full documentation and a pointer to the mailing list, see the rdiff-backup project home page at http://rdiff-backup.nongnu.org/.