Upgrade note; if you've used version 0.2.2 or lower, please
move the following lines from ~/.rsync-backup/localbackuponly to
~/.rsync-backup/exclude :

/home/*/.dontbackup/
/root/.dontbackup/


 	First off, I'd like to thank everyone that's worked on rsync and
ssh and openssh.  This project was able to take off so quickly because
those packages do their respective jobs so well.
	Executive summary: I've put together some shell scripts that
automate the rsync/ssh backup process and satisfy some pretty strict
security requirements.  I'm making them available so that others can use
them, and would appreciate any feedback.  See:
ftp://ftp.stearns.org/pub/wstearns/rsync-backup/
	I had been asked by a coworker to set up a backup solution for
our office that wouldn't require shipping the entire contents of his
drive across the wire each day - rsync was going through my head before
he'd finished the sentence.  I decided to put together a few scripts to
automate the backup; here are the goals:

- Encrypt the backup going across the wire.
- Only ship changed data.

	The above could be handled by the one-liner in the rsync faq.
However, I also wanted:

- Run server as root to preserve permissions and ownership.
- Keep people from seeing each other's backups.

	Giving people access to a root or root equivalent account means
running the server chrooted.  Not a truly big deal, as long as we have a
statically linked rsync at the server end.

- Don't require the server to trust any files sent from the clients.
- Don't even trust that the client will send a correct "rsync -server..."
command; hardcode that at the server.
- Don't ship password files, key files, and other sensitive files across
the wire; back them up locally.

	Shipping _everything_ off to one machine makes that machine a
single point of failure, essentially, if the backup server was broken
into.  That's why I'd prefer that /etc/shadow, ssh keys, ipsec keys,
etc, be backed up locally.

- Allow for a very large number of daily snapshots by using hardlinks on
the server drive.
- Don't require more than 2-4 times the combined client capacity on the
server by hardlinking files even between client backups.

	If it weren't for hardlinks, the last two requirements would
contradict each other.  By using "cp -av --link" to make the snapshots
and running freedups *1 once a week to link identical files that aren't
already hardlinked, I suspect that the 2x-4x bound should be quite
reasonable, especially if a number of the client systems are using the
same distribution.

- Allow admin to use one key for everyone (backups named after the client
IP) or allow named backups (when a machine may change ip or multiple
independant backups may need to be made from one machine).
- The backups could very well be stored in an encrypted container on the
server; one would set up an encrypted loop mount under /backups.  My
package doesn't do anything about that because it's a local mounting
issue.

	The rsync-backup package includes a client and server rpm (tar
available).  I don't know of any reason it couldn't work on any *nix
platform with rsync, ssh, and bash.  The server needs a statically
compiled version of rsync in server:/usr/bin/rsync-static; I really
didn't feel like futzing around with shared libraries in a chroot
environment. I've made up an rpm for this too.  Andrew - would you
consider putting static rpms at the main site?  For those that would
prefer to compile their own from the source tar, simply make
CFLAGS="-static" and copy the resulting rsync binary to
/usr/bin/rsync-static .

 	The 0.2 release is a generally functional package.  It needs a
lot of work, but I'm releasing it for those that are interested. 
Feedback, requests, patches are all welcome.
	To install the ssh keys, please get the ssh-keyinstall package.
 	The astute code reader
may notice a glaring lack of any reference to, ahem, the _restore_
process.  *grin*  Don't worry, it's in design.  I hope to make the
entire restore process run from a single floppy linux, so when a
replacement drive shows up, the admin can boot the system from a Toms
root/boot and do the restore with no more than two floppies and an
Ethernet connection.  Until then, the files could be copied to a
replacement drive right off the backup server subdirectory.
 	One last request.  The package includes a list of files that I
think should be backed up locally because of their password or security
related nature.  I would love to hear from others about additional
password-type files that should be skipped.

*1 Freedups is also a shell script that searches for identical files and
hardlinks them; if it's installed, the weekly maintenance script will
use it.  I've found I can easily save 30% of the server drive space used
with only 3 machines backed up, because the systems share so many
identical files.

References:
rsync-backup package:
	http://www.stearns.org/rsync-backup/
	http://freshmeat.net/projects/rsync-backup/
rsync:
	http://rsync.samba.org
rsync-static
	http://www.stearns.org/rsync-static/
ssh:
	http://www.ssh.com
Openssh:
	http://www.openssh.org
ssh-keyinstall
	http://www.stearns.org/ssh-keyinstall/
freedups:
	http://www.stearns.org/freedups/
	http://freshmeat.net/projects/freedups/