Read on for an explanation of what versioned backups and hardlinks are, why they are good, and what you have to do to make RsyncX do what it should.
First, let's turn to versioned backups: This means that you won't have only one backup of your hard drive, but several ones -- the newest one, plus older versions, too, in order to be able to find files you have deleted some time ago. They won't be present in your latest backup, as they were already deleted at that time, but you can still retrieve them from older backups. If every version of your backup used the complete space of all the files on your internal (or main) hard drive, however, you'd soon have massive amounts of space wasted on your backup drive.
Enter hardlinks. Hardlinks are a very clever concept that unix file systems use. (NTFS is able to use them, too, though Windows doesn't come with any tool to actually use that feature.) In short: You may have several directory entries (in the same or different directories, with different names, if you want) pointing to the same actual data on your drive. For example, you have a the files /foo/bar/one and /bar/baz/two that really are the same file. Both directory entries point to the same data on the drive.
And now the really clever part: The file system knows how many directory entries point to an inode, that is (simply put) the actual data of the file. If you delete /foo/bar/one, /bar/baz/two will still exist and the inode won't be deleted. Only if you also delete /bar/baz/two will the space on the drive be freed, and the data deleted.
Now that's perfect for versioned backups! Suppose you want three backup versions on your backup drive, residing in three directories called backup1, backup2, and backup3. When you back up for the first time, all files from your main drive will be copied to the backup drive, into directory backup1. When you back up for the second time, backup1 will be renamed to backup2. All files in the newly-created backup1 that did not change will just be hardlinks to files already present in backup2 -- and thus won't use any additional space. Both backup1 and backup2 are fully usable copies of your main drive, though. This means you could just copy them back to your main drive wihout the hassle of incremental backups, where you have to use a full backup and then commit back all the changes saved to the incremental backups since then.
Suppose you back up for the fourth time. backup3 will be deleted -- which means that only the data that was different from backup2 will be _actually_ deleted, the rest is still there, as directory entries from backup2 (and maybe backup1) still point to the data. Now backup2 is renamed to backup3, backup1 is renamed to backup2, and the new backup can be copied/hardlinked to your backup drive.
This is a copy, of course, so the files are not compressed. It's not a very good idea to compress backups, though, as you normally want the best data safety you can get. In compressed files, one wrong bit may render the whole file unusable, which is even worse if your whole backup consists of only one file.
I had this idea of versioned backups with hardlinks, and I was looking for a tool that used this technique -- which rsync does. rsync is a unix tool that can mirror directories, or whole file systems, to other directories, other file systems, and even over the network. The rsync that comes with Mac OS X isn't HFS+-aware, though -- it won't copy resource forks. And it requires a good amount of manpage reading and command line fiddling to have it do what you want to.
Enter RsyncX. First, it provides you with an rsync version that will copy resource forks. Second, it comes with a neat graphical UI where you just have to point and click to tell it what you want, and it will produce a shell script that does just that. It can even set up a cron job for you that will execute your backup script every night, or whenever you want to. There are some things you should know, though, to make it work as it should.
First, hardlinks for back up purposes will only work if the user and file permissions are not ignored on your backup drive. Simple reason: If they are ignored, your script (run as root by crond) will see all backed up files as belonging to root:wheel. The files on your main drive have different owners and permissions, though, so there IS a difference between the file from the last backup and the file on your main drive. This means that rsync will copy, not hardlink, the file. So you will end up with a full copy of the file, instead of a hardlink, even if the file hasn't changed.
So before you run your backup script for the first time, be sure control-click on the icon of your backup drive, select Get Info, and then uncheck the box next to "Ignore owners on this volume," near the bottom of the window.
Second, at least on Tiger, RsyncX will save your backup script as TheNameYouChose.scpt, but set up a cron job with only /Path/To/TheNameYouChose. You will have to rename TheNameYouChose.scpt to TheNameYouChose for the cron job to work. I submitted this bug to the developers, but never got an answer -- maybe they silently corrected it meanwhile, maybe not.
That's it.
You now have a perfect versioned backup solution, it's free, and it works just great. Personally, I have the cron job run every night, and I have seven versions of my main drive in my backups. Which makes me feel much safer than before.

