Up one level
COPYING 17982 Jan 23 1996
CREDITS 467 Mar 29 2001
ChangeLog 1708 Jun 1 2003
FAQ 1417 Jun 1 2003
INSTALL 4997 Jun 1 2003
Makefile 6152 Jun 1 2003
NEWS 0 Mar 28 2001
README 5261 Jun 1 2003
TODO 561 Sep 4 2002
exclude.default 216 Jun 1 2003
favicon.ico 23 Aug 28 2005
index.html 11782 Mar 7 2003
internal-gopher-menu 32 Aug 28 2005
internal-gopher-unknown 35 Aug 28 2005
localbackuponly.default 1704 Jun 1 2003
redhat Feb 21 2005
redhat/rsync-backup.spec 5928 May 29 2003
rsync-backup-client 4306 Jun 1 2003
rsync-backup-daily-maintenance 1791 Jun 1 2003
rsync-backup-server 3043 Jun 1 2003
rsync-backup-weekly-maintenance 2964 Jun 1 2003


	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 May 12 23:45:18 EDT 2006 by htmlfilelist version 0.8.4