Up one level
COPYING 17982 Jan 23 1996
CREDITS 467 Mar 29 2001
ChangeLog 1244 Sep 4 2002
FAQ 954 Apr 16 2001
INSTALL 4887 Aug 29 2002
Makefile 6148 Sep 4 2002
NEWS 0 Mar 28 2001
README 5264 Aug 29 2002
TODO 561 Sep 4 2002
exclude.default 175 Aug 29 2002
favicon.ico 23 Jan 20 01:26
internal-gopher-menu 32 Jan 20 01:26
internal-gopher-unknown 35 Jan 20 01:26
localbackuponly.default 1646 Aug 29 2002
redhat Nov 18 2001
redhat/rsync-backup.spec 5928 Sep 4 2002
rsync-backup-client 4217 Sep 4 2002
rsync-backup-daily-maintenance 1736 Aug 15 2002
rsync-backup-server 3018 Sep 4 2002
rsync-backup-weekly-maintenance 2065 Aug 15 2002


	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 :


 	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:
	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

	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.

rsync-backup package:

The files in this collection are part of William Stearns' software archive. If any of the links on this page do not work, you may be viewing an incomplete mirror. There is a complete list of the mirror sites at the starting page for this mirror and at the primary mirror.

Generated Fri Mar 7 13:56:44 EST 2003 by htmlfilelist version 0.8.1