>> > There is no sacrifice, you are running rsync as root on the client >> > either way. Alternatively, you could run rsyncd on the client, which >> > avoids the need for the server to be able to run an SSH session. >> >> I think the sacrifice is that with the backuppc method, if someone >> breaks into the backup server they will have read(/write) access to >> the clients. The method I'm describing requires more management if >> you have a lot of machines, but it doesn't have the aforementioned >> vulnerability. >> >> The rsyncd option is interesting. If you don't want to restore >> directly onto the client, there are no SSH keys involved at all? > > Not even then, the server talks to the client in the same way for > restores as it does for backups, so it would still use rsyncd if you > wanted it to.
Hmmm, now that I think about it, I guess the server accessing the client via rsyncd still provides the server with root read/write access to the client just like SSH keys. > I don't think it too unreasonable to assume that a machine with no ports > exposed to the Internet will not be compromised from the Internet. > Whereas a push approach requires that the server have open ports. Agreed, but this requires that the backup server is local to the admin which may not be possible. openvpn requires open ports of course. There's also the possibility of a local break-in.... - Grant
