On Thu, 2009-11-19 at 08:44 -0800, Grant wrote:
> I just finished an rsync backup system that works like this:
>
> Each of 4 Gentoo systems contains a folder called "backup" which
> contains symlinks to local files and folders for backup. 2 of the
> systems contain a folder called "sync" which contains the contents of
> the "backup" folder for each of the 4 systems. 3 of the systems rsync
> with one of the "sync" systems, and that system rsyncs with the other
> "sync" system.
>
> I've got a few questions for you guys about this.
>
> 1. I back up the entire /etc folder of each system, and some files
> have read-only permissions. This means I get "permission denied" when
> I try to rsync them. How would you handle this?
I've never had this problem. You should only need read permissions to
copy a file:
$ touch this
$ chmod 0400 this
$ rsync -a this that
$ /bin/cp -f /etc/issue this
$ chmod 0400 this
$ rsync -a this that
$ ls -l this that
4.0K -r-------- 1 percy users 3 Nov 19 12:38 that
4.0K -r-------- 1 percy users 3 Nov 19 12:38 this
> 2. Some of the files I back up only allow root to read. I can run
> rsync as root on each system, but I don't allow root logins. This
> means in order to rsync the second "sync" system with the first "sync"
> system, I must run the rsync command from the first "sync" system.
> This means I have to run rsyncd on the second "sync" system in
> addition to the first "sync" system. I'd rather only run one instance
> of rsyncd. Can anyone think of another option?
>
Well if #1 was not run as root then this is where you have problems.
And you will continue to have problems if you don't copy as root or some
user who has at least read access to all the files on each source and
can also preserve ownership/permissions on the target system. Like...
root.
ssh. Why are you using rsyncd anyway? AFAIK rsyncd is not encrypted.
You can allow a non-root user to ssh in and run rsync as root via a
proxy command. You can also configure sshd to only allow root to log in
and execute a particular command (such as rsync). See PermitRootLogin
and ForcedCommand under ssh_config(5)
> 3. The rsync process always completes with "rsync error: some
> files/attrs were not transferred". How can I get more information
> about which files this pertains to?
It should spit it out to stderr. If you using -v they probably scrolled
by. Redirect stderr to a file. If you are running rsync as non-root
then it can't preserve ownership and some perms. If you are using
extended attributes/ACLs and did not tell rsync to use them (or comple
support in) or if the target system does not support them then they will
not be transferred.
>
> 4. Should I be comfortable running the entire sync operation every
> night, or am I jeopardizing the longevity of my HDs?
>
This is a joke.
> 5. If I end up with filesystem corruption on the SRC system, will that
> corruption transfer over to the DST system during an rsync, or will
> the transfer just fail?
>
If the filesystem returns an error to rsync then rsync will error out.
Simple as that. If the file is currupt (not the filesystem) then,
standard garbage-in/garbage-out rules apply.
> 6. Can I run rsyncd on a system facing the internet without fear?
No. Rsyncd is not encrypted (see above) also the authentication is weak
(see the man page).
Use ssh. It's more secure and had better lock-down mechanisms. Better
yet, use a VPN and ssh through the VPN (double authentication (and
encryption)).
