Gentoo Archives: gentoo-server

From: Jonathan Rogers <jonner@××××××.net>
To: gentoo-server@l.g.o
Subject: Re: [gentoo-server] backups/mirroring with rsync
Date: Sat, 30 Oct 2004 23:47:37
Message-Id: 41842813.30601@teegra.net
In Reply to: [gentoo-server] backups/mirroring with rsync by Ben Munat
1 Ben Munat wrote:
2 > Hello,
3 >
4 > So, I decided to keep things "simple" and just use rsync for backing up
5 > my web server. But now I'm wondering if "simple" was the right word...
6 > my head is spinning with all the possible configuration and command-line
7 > argument permutations. Below is my plan... if there are any rsync
8 > experts out there, I'd love to hear thoughts, warnings, advice, etc.
9
10 I'd recommend that you use rdiff-backup, since it is as simple to use as
11 rsync and gives you the added benefit of file history, rather than only
12 a snapshot. Configuring it is quite similar to rsync.
13
14 >
15 > I'm only using about 5 gigs on my server's drive. I have 50 gigs
16 > available on one partition alone on my home machine, so I'm planning on
17 > mirroring the server into a chroot on my home machine. My IP address has
18 > only changed once in the last four years, so that shouldn't be an issue.
19 >
20 > The initial sync will suck, but after that it shouldn't be too bad...
21 > not that much activity on this server. I'm figuring on setting up an
22 > hourly cron job on the server to run rsync. I'll also set up a user on
23 > my local machine just for this and have rsync chroot into that user's
24 > home directory.
25 >
26 > Then I'll just have the rsync start from "/" on the server. It doesn't
27 > seem like that much data to mess with picking and choosing. Plus, my
28 > hope is that if I should ever need this backup, I could just have the
29 > hosting company run my server from the gentoo cd and rsync the backup
30 > back onto the new drive.
31 >
32 > One question I have, however, is whether I need to exclude the /proc
33 > filesystem from the backup? Would that cause problems if I restored from
34 > the backup and then tried to boot the restored system? Or, hmmm,
35 > actually the /proc files are recreated on boot, right?
36
37 You should definitely exclude /proc. You probably also want to exclude
38 /dev, especially if it is devfs or udev (which it almost certainly is).
39 I also exclude /tmp, but that's up to you.
40
41 Another issue is data security. I exclude ".ssh" directories, since they
42 contain private keys, which should never exist anywhere except where
43 they were created. However, this is not an optimal setup, so I'm
44 considering moving to a backup system that always stores everything
45 encrypted.
46
47 >
48 > Someone told me that having the rsync server running on both machines
49 > makes things go faster... though I'm not clear on how you do that. Is
50 > this as simple as adding the "--server" option to the command? I was
51 > also planning on doing this over ssh to get encryption and to get
52 > through my firewall.
53
54 AFAIK, an rsync server has no inherent speed advantage. Setting up a
55 server is how one makes files publicly available, such as the portage
56 tree. However, you certainly don't want any of your data public.
57
58 You certainly want to use ssh or some other network transport that
59 encrypts everything. This will impose processing overhead on both hosts,
60 but it's absolutely essential for private data.
61
62 OpenSSH can use several block ciphers for stream encryption, several of
63 which are much faster than the default. Google it for details. Here is
64 some info on that:
65 <URL:http://www.linuxjournal.com/article.php?sid=6602>
66
67 >
68 > So, here's what I think I need to do: Make my new user on my local
69 > machine (say, "backup-user", for example), giving him a home dir (/home
70 > is on it's own partition with 50 gigs free). Then I set up the
71 > rsyncd.conf file on my local machine with a module called, for example,
72 > "server-backup", give it the path "/home/backup", and say, "use
73 > chroot=yes". I suppose I could also put in a "hosts allow" clause with
74 > my server's IP address.
75
76 Again, I don't think there's any advantage to using rsyncd rather than
77 just having rsync run from ssh; indeed, the two methods are mutually
78 exclusive, AFAIK.
79
80 >
81 > Then, on the server, I put a script in the cron.hourly folder that just
82 > says something like:
83 >
84 > rsync -az -e ssh --delete --server --password-file=~secret /
85 > backup-user@<my ip address>::server-backup
86 >
87 > (but all on one line...)
88 >
89 > If I've got this right, that would tell rsync to use "archive" mode
90 > (preserving permissions and ownership) and compression. It would then
91 > connect over ssh to my home machine as "backup-user", getting the
92 > password from a (chmod 600!) file called "~secret", and sync everything
93 > under "/" on the server into "/home/backup-user" (which is the path for
94 > the "server-backup" rsync module), chrooted in that directory.
95 >
96
97 Rsync will only be able to preserve ownership and permissions if it runs
98 as root on the backup machine. This is a security issue that is
99 hopefully mitigated by running in a chroot, but consider it carefully.
100
101 > Oh crap... I just noticed that the man page says, if I'm understanding
102 > it correctly, that chroot isn't available unless I connect as root. That
103 > seems dumb... rsyncd is running as root on my machine, it should be able
104 > to chroot. Not that I really need the chroot I guess... I'm allowing
105 > only my server to connect, so I suppose I'll just skip that.
106 >
107 > Anyway, sorry this is so long... but I wanted to make sure I have this
108 > all correct before I go trying anything. Though, I suppose I'll use that
109 > "-n" dry-run option before actually doing this anyway.
110 >
111 > Well, thoughts and observations much appreciated...
112
113 I hope I can be of some help.
114
115 Jonathan Rogers