| 17982 | Jan 23 | 1996 | |
| 467 | Mar 29 | 2001 | |
| 1244 | Sep 4 | 2002 | |
| 954 | Apr 16 | 2001 | |
| 4887 | Aug 29 | 2002 | |
| 6148 | Sep 4 | 2002 | |
| 0 | Mar 28 | 2001 | |
| 5264 | Aug 29 | 2002 | |
| 561 | Sep 4 | 2002 | |
| 175 | Aug 29 | 2002 | |
| 23 | Jan 20 | 01:26 | |
| 32 | Jan 20 | 01:26 | |
| 35 | Jan 20 | 01:26 | |
| 1646 | Aug 29 | 2002 | |
| Nov 18 | 2001 | ||
| 5928 | Sep 4 | 2002 | |
| 4217 | Sep 4 | 2002 | |
| 1736 | Aug 15 | 2002 | |
| 3018 | Sep 4 | 2002 | |
| 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 : /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: ftp://ftp.stearns.org/pub/wstearns/rsync-backup/ http://freshmeat.net/projects/rsync-backup/ rsync: http://rsync.samba.org rsync-static ftp://ftp.stearns.org/pub/wstearns/rsync-static/ ssh: http://www.ssh.com Openssh: http://www.openssh.org ssh-keyinstall ftp://ftp.stearns.org/pub/wstearns/ssh-keyinstall/ freedups: http://freshmeat.net/projects/freedups/
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.