1 |
Hello, |
2 |
|
3 |
So, I decided to keep things "simple" and just use rsync for backing up |
4 |
my web server. But now I'm wondering if "simple" was the right word... |
5 |
my head is spinning with all the possible configuration and command-line |
6 |
argument permutations. Below is my plan... if there are any rsync |
7 |
experts out there, I'd love to hear thoughts, warnings, advice, etc. |
8 |
|
9 |
I'm only using about 5 gigs on my server's drive. I have 50 gigs |
10 |
available on one partition alone on my home machine, so I'm planning on |
11 |
mirroring the server into a chroot on my home machine. My IP address has |
12 |
only changed once in the last four years, so that shouldn't be an issue. |
13 |
|
14 |
The initial sync will suck, but after that it shouldn't be too bad... |
15 |
not that much activity on this server. I'm figuring on setting up an |
16 |
hourly cron job on the server to run rsync. I'll also set up a user on |
17 |
my local machine just for this and have rsync chroot into that user's |
18 |
home directory. |
19 |
|
20 |
Then I'll just have the rsync start from "/" on the server. It doesn't |
21 |
seem like that much data to mess with picking and choosing. Plus, my |
22 |
hope is that if I should ever need this backup, I could just have the |
23 |
hosting company run my server from the gentoo cd and rsync the backup |
24 |
back onto the new drive. |
25 |
|
26 |
One question I have, however, is whether I need to exclude the /proc |
27 |
filesystem from the backup? Would that cause problems if I restored from |
28 |
the backup and then tried to boot the restored system? Or, hmmm, |
29 |
actually the /proc files are recreated on boot, right? |
30 |
|
31 |
Someone told me that having the rsync server running on both machines |
32 |
makes things go faster... though I'm not clear on how you do that. Is |
33 |
this as simple as adding the "--server" option to the command? I was |
34 |
also planning on doing this over ssh to get encryption and to get |
35 |
through my firewall. |
36 |
|
37 |
So, here's what I think I need to do: Make my new user on my local |
38 |
machine (say, "backup-user", for example), giving him a home dir (/home |
39 |
is on it's own partition with 50 gigs free). Then I set up the |
40 |
rsyncd.conf file on my local machine with a module called, for example, |
41 |
"server-backup", give it the path "/home/backup", and say, "use |
42 |
chroot=yes". I suppose I could also put in a "hosts allow" clause with |
43 |
my server's IP address. |
44 |
|
45 |
Then, on the server, I put a script in the cron.hourly folder that just |
46 |
says something like: |
47 |
|
48 |
rsync -az -e ssh --delete --server --password-file=~secret / |
49 |
backup-user@<my ip address>::server-backup |
50 |
|
51 |
(but all on one line...) |
52 |
|
53 |
If I've got this right, that would tell rsync to use "archive" mode |
54 |
(preserving permissions and ownership) and compression. It would then |
55 |
connect over ssh to my home machine as "backup-user", getting the |
56 |
password from a (chmod 600!) file called "~secret", and sync everything |
57 |
under "/" on the server into "/home/backup-user" (which is the path for |
58 |
the "server-backup" rsync module), chrooted in that directory. |
59 |
|
60 |
Oh crap... I just noticed that the man page says, if I'm understanding |
61 |
it correctly, that chroot isn't available unless I connect as root. That |
62 |
seems dumb... rsyncd is running as root on my machine, it should be able |
63 |
to chroot. Not that I really need the chroot I guess... I'm allowing |
64 |
only my server to connect, so I suppose I'll just skip that. |
65 |
|
66 |
Anyway, sorry this is so long... but I wanted to make sure I have this |
67 |
all correct before I go trying anything. Though, I suppose I'll use that |
68 |
"-n" dry-run option before actually doing this anyway. |
69 |
|
70 |
Well, thoughts and observations much appreciated... |
71 |
|
72 |
Ben |