1 |
On Thu, 2009-11-19 at 08:44 -0800, Grant wrote: |
2 |
> I just finished an rsync backup system that works like this: |
3 |
> |
4 |
> Each of 4 Gentoo systems contains a folder called "backup" which |
5 |
> contains symlinks to local files and folders for backup. 2 of the |
6 |
> systems contain a folder called "sync" which contains the contents of |
7 |
> the "backup" folder for each of the 4 systems. 3 of the systems rsync |
8 |
> with one of the "sync" systems, and that system rsyncs with the other |
9 |
> "sync" system. |
10 |
> |
11 |
|
12 |
> I've got a few questions for you guys about this. |
13 |
> |
14 |
> 1. I back up the entire /etc folder of each system, and some files |
15 |
> have read-only permissions. This means I get "permission denied" when |
16 |
> I try to rsync them. How would you handle this? |
17 |
|
18 |
I've never had this problem. You should only need read permissions to |
19 |
copy a file: |
20 |
|
21 |
$ touch this |
22 |
$ chmod 0400 this |
23 |
$ rsync -a this that |
24 |
$ /bin/cp -f /etc/issue this |
25 |
$ chmod 0400 this |
26 |
$ rsync -a this that |
27 |
$ ls -l this that |
28 |
4.0K -r-------- 1 percy users 3 Nov 19 12:38 that |
29 |
4.0K -r-------- 1 percy users 3 Nov 19 12:38 this |
30 |
|
31 |
|
32 |
> 2. Some of the files I back up only allow root to read. I can run |
33 |
> rsync as root on each system, but I don't allow root logins. This |
34 |
> means in order to rsync the second "sync" system with the first "sync" |
35 |
> system, I must run the rsync command from the first "sync" system. |
36 |
> This means I have to run rsyncd on the second "sync" system in |
37 |
> addition to the first "sync" system. I'd rather only run one instance |
38 |
> of rsyncd. Can anyone think of another option? |
39 |
> |
40 |
Well if #1 was not run as root then this is where you have problems. |
41 |
And you will continue to have problems if you don't copy as root or some |
42 |
user who has at least read access to all the files on each source and |
43 |
can also preserve ownership/permissions on the target system. Like... |
44 |
root. |
45 |
|
46 |
ssh. Why are you using rsyncd anyway? AFAIK rsyncd is not encrypted. |
47 |
You can allow a non-root user to ssh in and run rsync as root via a |
48 |
proxy command. You can also configure sshd to only allow root to log in |
49 |
and execute a particular command (such as rsync). See PermitRootLogin |
50 |
and ForcedCommand under ssh_config(5) |
51 |
|
52 |
> 3. The rsync process always completes with "rsync error: some |
53 |
> files/attrs were not transferred". How can I get more information |
54 |
> about which files this pertains to? |
55 |
|
56 |
It should spit it out to stderr. If you using -v they probably scrolled |
57 |
by. Redirect stderr to a file. If you are running rsync as non-root |
58 |
then it can't preserve ownership and some perms. If you are using |
59 |
extended attributes/ACLs and did not tell rsync to use them (or comple |
60 |
support in) or if the target system does not support them then they will |
61 |
not be transferred. |
62 |
|
63 |
> |
64 |
> 4. Should I be comfortable running the entire sync operation every |
65 |
> night, or am I jeopardizing the longevity of my HDs? |
66 |
> |
67 |
This is a joke. |
68 |
|
69 |
> 5. If I end up with filesystem corruption on the SRC system, will that |
70 |
> corruption transfer over to the DST system during an rsync, or will |
71 |
> the transfer just fail? |
72 |
> |
73 |
If the filesystem returns an error to rsync then rsync will error out. |
74 |
Simple as that. If the file is currupt (not the filesystem) then, |
75 |
standard garbage-in/garbage-out rules apply. |
76 |
|
77 |
> 6. Can I run rsyncd on a system facing the internet without fear? |
78 |
|
79 |
No. Rsyncd is not encrypted (see above) also the authentication is weak |
80 |
(see the man page). |
81 |
|
82 |
Use ssh. It's more secure and had better lock-down mechanisms. Better |
83 |
yet, use a VPN and ssh through the VPN (double authentication (and |
84 |
encryption)). |