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 |